It amazes me that the constant complaint on here is the price. Seriously folks, if you are a professional developer (by that I mean your primary ability to earn money for you and your family is the development of software) then the cost of a Xamarin license should be looked at as a factor of time.
How much time will it save you? Lets imagine your current project to build an iOS and Android app of identical functionality you are estimating at 6 weeks for each platform. 12 total weeks. Lets say that Xamarin tech gives you a 10% boost (it will be much higher but lets be conservative), that means over the 60 business days, you get back 6. Assume you have 8 hours of work per day and you just bought 48 hours of your time. The basic license which does nearly everything most people need is the Indie license and $300 per platform. Six hundred dollars to buy 48 hours of your time back means the purchase is viable if you value your time at more than 12.50 per hour.
If you value your time less than that, you have bigger problems than which mobile tooling to use.
The truth is the productivity factor is much higher than 10% and the license is good for a year, pick up a couple other projects like this through the year and that number collapses. For me this year I will probably do 4 cross plat projects with Xamarin and my productivity diff is north of 50%. The purchase is a no brainer.
It amazes me that you've completely missed out on some of the reasons for people complaining about the cost. My comment is one you're railing against and I think you're off base. Even going by your factor of time, I have to bet $1,000 that this product will be worth both that money and the time that I have to put into learning and dealing with it. There's no VS trail (as far as I know). So other than going off of blog posts and advice, I have to pay at least $300 and then learn both the tool and it's IDE or gamble an extra $700 that it will be useful in an IDE/environment I'm already familiar with.
Here's the problem: it's too expensive to learn on my own, and I can't advocate for C#, F# or Mono without already being an expert. Yes, I am a professional software engineer, and I support my family that way. But I have other expenses and interests, too, and blowing money on a compiler/IDE/platform just so I can play with it in my spare time doesn't really work for me.
Think of it another way: how do you plan to grow the next generation of engineers if they can't afford your technology to learn on, but they can download a JDK and a good Scala IDE for free?
Moreover, I'm not sure how you're arriving at a 10% productivity gain without knowing what I'm already working on. It may be 10% compared to Objective C for iOS, but is it 10% for my server-side Scala project?
I think you are missing the point here so I'll layout the three reasons price is a big deal to some (I'm basing my arguments on the ($1000 per platform price because that is the first place I think it's really worth while):
1. If I'm bootstrapping a startup, That $2000 is easily at least 1 entire year of web hosting, or a new MacBook, or a couple of new servers. Bootstrapping has thin enough margains that $2000 is a large amount of money and runway for a young company and that's only for one dev. Have two dev's? that's even more of your runway gone. $4000 could sustain two devs for two months if they are really cheap and try hard. Xamarin is unlikely to save you that two months.
2. If I'm developing an indie game there are A HUGE amount of cheaper better options available. Unity, Unreal, Cry Tech, cocos2D/3D, or Apportable. All cheaper and better for game dev.
3. If I'm learning how to develop mobile apps with the hope of obtaining a full time job. Then Xamarin job posts are fairly rare, so spending even $600 to learn the dev process and then still not have the skills to get a full time position is a losing value equation.
4. There are cheaper tools out there, like Ruby Motion or Apportable.
I think the Xamarin guys are brilliant and made a great product but I think the value is very limited to existing Dot Net or independent app developers. Yes it makes a lot of sense for those groups but there are a ton of others that the price is a real barrier to entry.
To add to this: think about the target market for this. It's not the person who knows objective-c and wants to make an Android app. It's not the person who knows Java and wants to make an iOS app. It's the person who already knows .NET and wants to make an app for either of those platforms.
I guess I also made a fundamental mistake in the above sentences. It's not a person, but rather a business that is looking at it. In the .NET world, it's common to have an MSDN license for each developer. Looking at the costs from that perspective and the licensing costs for Xamarin make a lot more sense.
The killer problem with Xamarin is to use it effectively you have to be expert in both Xamarin and the native platform you're targeting. This is because most of the work of mobile apps ends up being tied to the UI, which has a platform specific API.
If your app happens to deviate from this, then at least for Android once more you're in platform specific land (for example, services), but I've seen people doing things like rolling their own ghetto mini database in C# to give themselves a portable data model, when it would be faster to use SQLite on Android and iOS, just to justify the decision to use Xamarin at all.
So, it can work, but people have a tendency to greatly overestimate how much of a mobile app can actually be platform independent anyway. Games are a different proposition, and this is one reason why Unity has cleaned up.
YMMV but for me, there was not 'learning' of Xamarin. There really is no Xamarin framework - there is the mobile frameworks themselves for which there is an almost 1:1 translation. CalculateFoo in ObjC or Java will in nearly every case be CalculateFoo in C#. In the cases where the recommended method is to use a higher level abstraction (like for table data in iOS), the option to use a mirror of the ObjC pattern is there but there is an easier approach available if you choose that.
The key for me was understanding the idiosyncrasies of both Android and iOS and their patterns and then using C# to craft as much reusable code as possible. It drives my approach and I failed to get the re-use level I wanted on my first true cross platform app build, but since I have learned those lessons I have gotten much better at it.
(note: I have yet to use Xamarin.Forms, this experience is based on Xamarin in the past 15 months)
The power of Xamarin is obviously that you have a single language (C#) even if you have a "fat" UI's that are platform specific. Having a single language means that you can have your business logic as a single code base rather than it in two or more languages with all the consequences of code base specific bugs.
But I do agree with you, Xamarin is not a build once run anywhere kind of solution. If you want to build Android app with it you still need to be very familiar with all the ins and outs of Android, same for iOS.
Someone mentioned Titanium earlier. Titanium shares the major advantages Paulo points out in his case for Xamarin (i.e. single language, cross-platform, native apps, access to native APIS). But Titanium also has a couple clear advantages over Xamarin:
- Titanium is FOSS - Xamarin's cost is merely very inconvenient; its closedness is much more repulsive
- Titanium doesn't sideline those of us who develop on linux (a linux-based OS rules the mobile market, after all)
On the other hand, C# is a beautiful, evolved language that I would love to try out with mobile development, and I can appreciate a shiny IDE. However, as long as the above conditions apply, I'll always consider open and developer-friendly solutions like Titanium first before resorting to Xamarin.
Xamarin's IDE is not as good as VS, but it is often much better than XCode, and C# and F# are both more pleasant languages to work in for people with the vast majority of experiences (C++, Java, .Net, Ruby), so even without all the cross platform goodness I prefer to work with Xamarin. (Swift may change some of that, I haven't looked into it yet).
I've never had a problem easily translating Obj C StackOverflows or blog posts to Xamarin/C# so essentially you get the whole community as well, with no worries about Xamarin specificness.
That said, I think their current pricing structure makes sense for them right now. They are not 'quite' at the polish level, not quite at the level that average people can do things averagely. There is still just a little more cross platform knowledge and effort required. The price serves as both a barrier to entry to manage the community size, and provides them enough capital (on top of outside investment) to keep investing toward a fully mass market approach.
I have done a lot amount of development in MonoTouch / MonoDroid (full time for about 2.5 years now). I started using them back when they were beta, and I would wager we have one of the larger apps written in Xamarin (about 250kloc).
First of all, it's tricky. It took our team a long time to get the rhythm of simultaneous Android/iOS development. For a long time every single push broke something.
Some annoyances:
Visual studio project files don't merge. You need a special xml aware merge tool to do this. Even then, its a pain in the ass.
It can be very tricky to abstract the differences between Droid and iOS if you're interacting with the OS a lot.
Some things to know:
Just because you're in C# land, doesn't mean your API is. You're going to spend a lot of time implementing stuff in C# that feels wrong because your API is ObjC/Java.
Sometimes there isn't a good mapping between NS data types between the APIs.
You're going to spend a LOT of time in the iOS / Droid docs, so you'd better be comfortable with ObjC / Java.
Personally I much prefer Ruby Motion to Xamarin. I like ruby more, it's a closer work flow to my standard python/django, Ruby/Rails based workflow (terminal and text editor based). Intellij provides a great ide (MUCH better than Xamarin studio, one of my least favorite IDE's all though visual studio is even better than intellij's offerings IMO). In version 3.0 they will offer Android support and at that point I think Ruby Motion will be the best native app option.
Almost forgot to mention that, all of the ruby is compiled down to actual Native obj-c runtime code. Great performance and look, as good as a regular Obj-C or Java app.
Thanks! I wasn't aware of that announcement. Last month's blog post says: "If you have a RubyMotion app for iOS or OS X and want to port it to Android, you can even share some of the code." (http://blog.rubymotion.com/post/87048665656/rubymotion-3-0-s...)
I haven't used Ruby Motion myself -- do you know how much of the code can be reused excluding platform-specific UI stuff? There's a significant difference between 5% and 95%. :)
I realize that the difference of $700 could be made up in improved development performance but I really, really wish they'd allow VS support for the indie license. It's not a case of saving more it's a risk/reward thing for me. I can see the possible value but, without being able to pick it up quickly in an environment I know I can't justify either spending an extra $700 or picking up another IDE/workspace along with the curve of mobile dev and setups for the different devices. Though I understand the cost, it provides tremendous value and you can't just give that away for free.
It's clear to me that Xamarin is trying to get everyone to pay right now. The free license won't even allow you to build the Xamarin.Forms demo, and Forms is one of the most significant new features they added. Cross platform apps with a common UI and codebase, no more separate views for each platform, and data binding! I think they're scaring off small developers by requiring the several hundred dollar investment to use Xamarin, even if it is a great product.
Where I work, we chose Xamarin over PhoneGap/Cordova.
It's a common misconception that phonegap and cordova don't have the same access to native APIs. They do, but they are limited by what plugins are available, and your ability or interest to build ones to fill the "gap."
For example, I wrote a plugin recently to send low-level broadcast UDP packets on Android and iOS through Cordova. The plugin API is just a bridge and sets up a calling convention for Javascript-to-native code.
100% true. I'm going to piss many off by this statement I'm sure... but if you are a web developer Xamarin offers no advantages against PhoneGap/Cordova I don't know anyone that is "just a C# developer" and hasn't done any web development, maybe Xamarin makes sense for those.
Take a look at Ionic Framework if you think PhoneGap/Cordova can't provide a native look and feel.
The big question IMHO is will Microsoft buy Xamarin or not. If they do the price will certainly fall drastically. On one hand it will give MS way more apps on their app store. On the other if Xamarin becomes very popular Apple may block Xamarin built apps from it's app store.
Apple tried blocking certain platforms in the past, at that time Xamarin wasn't included since they are following the guidelines set in Apple's developer terms of use. Apple changed their mind very quickly about that decision too.
Xamarin still requires a mac. Your code is still compiled using LLVM (or whatever engine Apple will introduce later). The resulting app that is uploaded to Apple looks just like an app that was built using XCode.
It will be interesting to compare a simple app and see the difference in the resulting package between Xamarin and XCode
You can't really compare them. MonoCross is a crossplat MVC framework that you use on top of Xamarin's Monotouch/droid/etc. to increase your shared code. Xamarin allows you to write about the same code for multiple platforms, but it doesn't make it easier to share the same exact code. E.g http://components.xamarin.com/view/xamarin.mobile
The code looks similar across platforms, but it's not exactly, the same - you can't make one change and have it carry across to all platforms. Monocross brings you closer to a write-once for all platforms experience.
It's the better choice for a number of reasons when the scale of the application(s) increases a lot. It's a premium product that comes loaded with features you need when you're building something at a scale larger than independently developing a single application.
But I think the main differences you'll find, irrespective of scale, are a powerful designer/storyboard tool, Visual Studio integration, and the kind of support you'd expect to find from a paid product.
Unless I'm mistaken, MonoCross isn't a replacement for Xamarin (formerly Monotouch and Monodroid). It's a layer on top that abstracts the platforms differences. You'd still need a Xamarin.iOS and/or Xamarin.Android license to use it.
There are so many factual errors and outdated assumptions in your thread that i wont take the time to do a writeup. To put it short:
- You're wrong.
- Given the current speed of Javascript on mobile, Xamarin is just a job creation tool for unemployed .NET/WPF Developers. - You cannnot reuse run-of-the-mill web devs for hybrid app development.
- Good web developers are just as expensive as good native devs.
- Hybrid app development is not easier than native development.
I forgot to add this to anyone who disagrees with this comment. Take a look at Ionic Framework if you think PhoneGap/Cordova can't provide a native look and feel.
keithwarren|11 years ago
How much time will it save you? Lets imagine your current project to build an iOS and Android app of identical functionality you are estimating at 6 weeks for each platform. 12 total weeks. Lets say that Xamarin tech gives you a 10% boost (it will be much higher but lets be conservative), that means over the 60 business days, you get back 6. Assume you have 8 hours of work per day and you just bought 48 hours of your time. The basic license which does nearly everything most people need is the Indie license and $300 per platform. Six hundred dollars to buy 48 hours of your time back means the purchase is viable if you value your time at more than 12.50 per hour.
If you value your time less than that, you have bigger problems than which mobile tooling to use.
The truth is the productivity factor is much higher than 10% and the license is good for a year, pick up a couple other projects like this through the year and that number collapses. For me this year I will probably do 4 cross plat projects with Xamarin and my productivity diff is north of 50%. The purchase is a no brainer.
atwebb|11 years ago
mjt0229|11 years ago
Think of it another way: how do you plan to grow the next generation of engineers if they can't afford your technology to learn on, but they can download a JDK and a good Scala IDE for free?
Moreover, I'm not sure how you're arriving at a 10% productivity gain without knowing what I'm already working on. It may be 10% compared to Objective C for iOS, but is it 10% for my server-side Scala project?
jaegerpicker|11 years ago
1. If I'm bootstrapping a startup, That $2000 is easily at least 1 entire year of web hosting, or a new MacBook, or a couple of new servers. Bootstrapping has thin enough margains that $2000 is a large amount of money and runway for a young company and that's only for one dev. Have two dev's? that's even more of your runway gone. $4000 could sustain two devs for two months if they are really cheap and try hard. Xamarin is unlikely to save you that two months.
2. If I'm developing an indie game there are A HUGE amount of cheaper better options available. Unity, Unreal, Cry Tech, cocos2D/3D, or Apportable. All cheaper and better for game dev.
3. If I'm learning how to develop mobile apps with the hope of obtaining a full time job. Then Xamarin job posts are fairly rare, so spending even $600 to learn the dev process and then still not have the skills to get a full time position is a losing value equation.
4. There are cheaper tools out there, like Ruby Motion or Apportable.
I think the Xamarin guys are brilliant and made a great product but I think the value is very limited to existing Dot Net or independent app developers. Yes it makes a lot of sense for those groups but there are a ton of others that the price is a real barrier to entry.
Glide|11 years ago
I guess I also made a fundamental mistake in the above sentences. It's not a person, but rather a business that is looking at it. In the .NET world, it's common to have an MSDN license for each developer. Looking at the costs from that perspective and the licensing costs for Xamarin make a lot more sense.
fidotron|11 years ago
If your app happens to deviate from this, then at least for Android once more you're in platform specific land (for example, services), but I've seen people doing things like rolling their own ghetto mini database in C# to give themselves a portable data model, when it would be faster to use SQLite on Android and iOS, just to justify the decision to use Xamarin at all.
So, it can work, but people have a tendency to greatly overestimate how much of a mobile app can actually be platform independent anyway. Games are a different proposition, and this is one reason why Unity has cleaned up.
keithwarren|11 years ago
The key for me was understanding the idiosyncrasies of both Android and iOS and their patterns and then using C# to craft as much reusable code as possible. It drives my approach and I failed to get the re-use level I wanted on my first true cross platform app build, but since I have learned those lessons I have gotten much better at it.
(note: I have yet to use Xamarin.Forms, this experience is based on Xamarin in the past 15 months)
pan69|11 years ago
But I do agree with you, Xamarin is not a build once run anywhere kind of solution. If you want to build Android app with it you still need to be very familiar with all the ins and outs of Android, same for iOS.
romanovic|11 years ago
jasallen|11 years ago
I've never had a problem easily translating Obj C StackOverflows or blog posts to Xamarin/C# so essentially you get the whole community as well, with no worries about Xamarin specificness.
That said, I think their current pricing structure makes sense for them right now. They are not 'quite' at the polish level, not quite at the level that average people can do things averagely. There is still just a little more cross platform knowledge and effort required. The price serves as both a barrier to entry to manage the community size, and provides them enough capital (on top of outside investment) to keep investing toward a fully mass market approach.
ogdenyogly|11 years ago
First of all, it's tricky. It took our team a long time to get the rhythm of simultaneous Android/iOS development. For a long time every single push broke something.
Some annoyances:
Visual studio project files don't merge. You need a special xml aware merge tool to do this. Even then, its a pain in the ass.
It can be very tricky to abstract the differences between Droid and iOS if you're interacting with the OS a lot.
Some things to know:
Just because you're in C# land, doesn't mean your API is. You're going to spend a lot of time implementing stuff in C# that feels wrong because your API is ObjC/Java.
Sometimes there isn't a good mapping between NS data types between the APIs.
You're going to spend a LOT of time in the iOS / Droid docs, so you'd better be comfortable with ObjC / Java.
Overall I'm happy with the experience.
jaegerpicker|11 years ago
Almost forgot to mention that, all of the ruby is compiled down to actual Native obj-c runtime code. Great performance and look, as good as a regular Obj-C or Java app.
mstromb|11 years ago
In fact, every app in the Apple app store is statically compiled. App store guidelines prohibit dynamic code generation, preventing the use of a JIT compiler: http://stackoverflow.com/questions/21689993/xamarin-ahead-of...
declan|11 years ago
I haven't used Ruby Motion myself -- do you know how much of the code can be reused excluding platform-specific UI stuff? There's a significant difference between 5% and 95%. :)
atwebb|11 years ago
AUmrysh|11 years ago
Where I work, we chose Xamarin over PhoneGap/Cordova.
pauloortins|11 years ago
zura|11 years ago
general_failure|11 years ago
yesimahuman|11 years ago
For example, I wrote a plugin recently to send low-level broadcast UDP packets on Android and iOS through Cordova. The plugin API is just a bridge and sets up a calling convention for Javascript-to-native code.
McGnarlySheen|11 years ago
Take a look at Ionic Framework if you think PhoneGap/Cordova can't provide a native look and feel.
cwyers|11 years ago
general_failure|11 years ago
gte910h|11 years ago
(Well, I guess I'd prefer to use it in F# too).
How well does it work to ignore the .Net parts and just use the nice IDE/Packaging/Not java story?
rational-future|11 years ago
EShy|11 years ago
Xamarin still requires a mac. Your code is still compiled using LLVM (or whatever engine Apple will introduce later). The resulting app that is uploaded to Apple looks just like an app that was built using XCode.
It will be interesting to compare a simple app and see the difference in the resulting package between Xamarin and XCode
sschalk|11 years ago
will_work4tears|11 years ago
mousetraps|11 years ago
The code looks similar across platforms, but it's not exactly, the same - you can't make one change and have it carry across to all platforms. Monocross brings you closer to a write-once for all platforms experience.
A better comparison is Monocross v.s. MvvmCross
edgyswingset|11 years ago
But I think the main differences you'll find, irrespective of scale, are a powerful designer/storyboard tool, Visual Studio integration, and the kind of support you'd expect to find from a paid product.
ilkhan4|11 years ago
sschalk|11 years ago
Have a nice weekend.
McGnarlySheen|11 years ago
McGnarlySheen|11 years ago
montspencer|11 years ago