Why choose Xamarin?
pauloortins.com
pauloortins.com
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.
You are right, there is a factor of learning that needs to be baked into your consideration but there comes a point where you put a little trust in people who came before you and tell you 'I have done this, I have been where you are - follow me and you will be fine'.
On the flip side, Nat Friedman is incredibly approachable. I am sure if you simply email him and tell him your concerns he will accommodate you with a longer trial period or some kind of money back guarantee, that just how he is.
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?
Lets just get expense out of the way because that argument is actually invalid. For professional devs like us, if you cannot learn something new enough to make a decision on it - in 30 days, then we have bigger problems than license fees.
If that is the case for you then money is not the issue, it is time. Having 30 free days for me to spend learning a tech is a unicorn, it does not exist.
I understand your frustration because there are so many amazing techs out there I wish I had the time to learn but just don't. I made the decision to invest my time in Xamarin when I realized that the custom mobile dev market is slowly eating the custom web appdev market I was doing so well in. I made a conscious decision to make a bet on Xamarin (mainly because I knew C# very well) because I saw value in their approach vs others.
I have been very successful financially in my career so it could be that I look at time and money different than others, especially college students learning CS, but my statements were aimed at pro devs.
(an aside, I think Xamarin offers very steep discounts to students)
You can do the same thing with a trial of Windows which actually lasts anywhere from 90 to 180 days or something.
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.
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.
The only way your math makes sense to me is if a start-up only plans on releasing for one platform at first. If you're going to build an iOS app first and only move on to Android if that iOS app is successful than it probably doesn't make sense to use Xamarin.
If you're planning on doing both iOS and Android at the same time (and maybe Windows Phone as well), the added developer hours (same dev or an additional dev) to build the same project in another language instead of sharing 50% of the code and just building another UI would probably cost you more.
I never heard anyone for Xamarin selling it as a game dev solution. IIRC Unity is actually running on the same Mono engine from Xamarin (it's an open source project, but I think they're running it). Last time I checked some of those other solutions had expensive licenses too.
Xamarin is still too new to see lots of job postings looking for that skill. I also think that in the near future companies using Xamarin will use it for LOB apps. That's a big market for .Net developers building desktop software or internal web sites. A transition to Xamarin might makes sense for both these companies and these developers.
The bottom line, products are targeted at specific customers. Xamarin could have decided to go after the start-ups, but since most start-ups are content with releasing an app on a single platform first, the proposition of getting additional platforms with less work isn't that enticing. It's much easier to sell the product to an enterprise as their cost for multiple teams with different skills would be a lot higher than the Xamarin license.
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.
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)
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.
- 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.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.
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.
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.
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%. :)
(Perhaps I'm overly cynical, though I've seen this before on other platforms.)
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...
I think I'd be willing to drop $300 of my own money if I could put my many years of C# experience to work developing iOS and Android apps.
The Xamarin toolchain has steadily improved and its PCL support makes a lot of things a lot easier, but I can't envision a use case where I would want to do my development in their IDE. I keep a Windows machine just to have VS so I can do the 90% case there and suffer through the 10% in XS.
Smart Indent, afaik, has been fixed. The problem you describe was only an issue for multi-line lambdas, iirc.
You know I like you guys, I loved doing GSoC with Mono and I wouldn't have interviewed over there if i didn't like what you're trying to do, but these issues make it really hard recommend Xamarin. Having my IDE make me legitimately mad is a bummer.
Where I work, we chose Xamarin over PhoneGap/Cordova.
http://lists.qt-project.org/pipermail/android-development/20...
It's native look and feel though, and not native integration. However AFAIK it goes to great lengths to blend in with the actual device you're running it on.
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.
Take a look at Ionic Framework if you think PhoneGap/Cordova can't provide a native look and feel.
(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?
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
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.
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
Was hoping to use it to learn some C# (beyond the simple hello world type of thing) - Xamarin's pricing is pretty steep for an amateur/hobbyist.
Have a nice weekend.