Develop Reference

Xamarin: comparison to native SDK and JS-based frameworks

So, one of the main features of coding using the native SDK provided by Android and iOS is the fact that you get not only a better performance, but also the look and feel of each platform: for example, on iOS, a tab-navigation bar would be located at the bottom of the screen, while in Android it is located at the top (yeah I know it also can be top and bottom, but you get my point), or also the Navigation Drawer dock is an Android navigation style while (as far as I know) there is nothing similar in iOS native sdk. My point being, you can feel the difference of platforms by their design guidelines which is a good thing, since it makes your app looks professional.
So taking that into account, in terms of performance and maintaining the feeling of your app, using JS-based frameworks like Titanium or PhoneGap will not make a wise choice.
Then comes Xamarin. As I read in here: Xamarin how it is getting the Native Look and Feel? it seems it is a C# wrapper for native SDK, which as far as I understand, it should not affect performance. But where's the look and feel part. Since XML layouts are not entirely what gives Android or iOS apps their feel, but also the navigation (which comes from the controller classes) how does Xamarin deals with these? It is said in their website that you can share code between platform, but will that also means I have to share navigation system and similar?
Finally, for the sake of "not writing code for each platform" , is it worth NOT to use native SDK and go with Xamarin (I don't really have a problem writing code for both iOS and Android), or is this framework target for C# developers so they won't have to learn Objective-C or Android.
Any extra explanation would be awesome, and thanks in advance.

I built a large application within the last year (2013) with different components: mainly an API (ASP.NET Web API => C#), a Website (ASP.NET MVC => C# + AngularJS), and both an app for Android (Xamarin.Android => C#) and iOS (Xamarin.iOS => C#). The decision to use Xamarin had its advantages and its disadvantages, but all in all I am more than happy with it.
As you can see in my list above, almost everything was done with C# (okay, the Website is mainly written in JavaScript ;-)). It's a wonderful mature language with really nice features (as LINQ). In my scenario it becomes clear: I did not have to learn and to perfect four languages (Swift/Objective-C, Java, C#, JavaScript) but only two: C# and JavaScript.
That comes especially into play regarding the code sharing aspect: our client applications aren't really thin clients because of some offline functionality which requires a lot of synchronization logic, so the UI part of the two apps is only one side of the medal. As it turned out, I could really use 90% of that non-interface code on both iOS and Android. This is an incredibly huge benefit, as it's not only about some language originalities of Swift/Objective-C or Java, but also about the different frameworks you are using on iOS and Android. To use the .NET Framework/Mono as foundation of every Xamarin app enables you to abstract things like data access or network communication from the underlaying OS.
In terms of speed and UI you don't have any disadvantages, because you're using the native APIs 1:1. Whatever is available on iOS or Android is also available through Xamarin. And whenever Apple for example ships a new version of iOS, Xamarin will ship the update for that within a few days, so you don't have to wait to be able to use newly introduced features by Apple.
Xamarin uses a technique called Ahead of Time Compiling on iOS, so everything you write in C# is compiled into the native iOS stuff before it is deployed to your device. That means there is no difference in what is executed between a "native" Objectice-C application and a Xamarin application (except some small overhead which isn't noteworthy from my experiences).
On Android Just in Time compilation is used as just with any other "native" Android app, too.
That all means you have all the exact same APIs and possibilities you would otherwise have, if you would go with Objective-C or Java. You even use the same objects for building your UI with the exact same types and names (sometimes slightly optimized ;)). So if you want a tab bar navigation for your app - you use a UITabBarController for that. See iOS vs. Xamarin.
After multiple years on my way with Xamarin I only one disadvantage:
Possible memory leaks. Their whole samples out there are a bunch of crap regarding essential basics of preventing memory leaks. If you are working with "expensive resources" like media files within your application, you should take care from day one. I had to get rid of all that problems when an app of mine had already been growing to up to 35 different (complex) dialogs. That took me almost two months or in other words thousands of bucks. They provide some documentation about it, but the tooling is poor at this end. And errors are likely to appear and very hard to be found (example).
But all in all it was one of my best decisions to go with Xamarin.

I have been coding with Xamarin for a while now. Its been great so far. Any problems I've had I figured it out because c# is my native language. The Xamarin site has many examples and API references for many features on all platforms.
Performance - You get native performance from using Xamarin. No questions asked. I have been using it to create audio, video and photo recording features for a new app i'm working on. Xamarin processes the c# code into native byte code for all platforms. Thats how this is achieved.
Look - The look of your app will be native. You literally have to use the Android xml format to make your user interface and the same Goes for IOS. You will still style your elements the same way you did on each platform. All Xamarin does is link a view to an event for you.
Api - The beauty of Xamarin is in the API. They ported the whole Android and IOS namespace to c#. Take a look at their Documentation.
Expensive - My only problem with Xamarin is that it is expensive. If you check their pricing it is outrageous. But you get what you pay for. A premium product that is backed by support.
C# - Sharp is a great language that has loads of support. The new async/await gets ride of the whole thread management issue. Json processing is super easy on the platform. I have uploaded several classes on Github that can be used for many apps.
If you are from a java background, brushing up on your c# skills will be a breeze.
The rdio app was created with Xamarin. Download it on Android and IOS and test its performance and enjoy its native look.
Best of Luck

There is much much more internet content, help, and support for native. That alone helps me make my choice. If you are really good at Xamerin, maybe 70% of the code you write will be usable by both apps, you still have to custom tailor things for each app.
But again, the support for native is so vast, that if you run into a proble, so has someone else.
With xamerin, well, good luck.
When I say app I mean iOS/Android

Which is easier to learn coming from a C# background: Objective C or Java?

I've used C# quite a lot, it was my main programming language during University and I wondered which of the two languages for developing for Android or iPhone are easiest to learn bearing that in mind.
I'm interested in people's opinions on the two languages, I've dabbled a little in both but nothing more than a couple of hours. I'm also interested in people's opinions on Windows Phone 7 as an app/game platform, as this uses C# so would be an obvious choice for transitioning into that area.
Opinions?

That would be Java but you will miss LINQ a lot.
You can develop in C# for the iPhone with MonoTouch but it's not free and you'll never know if Apple sends them out in the cold (unlikely). Soon you can even use C# for Android development with MonoDroid but I kind of feel that that's a smaller win for a C# programmer than not having to learn Objective-C. Java and C# are so close that the transition most probably will be smooth.
As a C# programmer I think that the Windows Phone 7 development platform looks very promising but my experience tells me to wait and see. Microsoft has a terrible track record in the mobile business and they also have a tendency to make big changes between early releases.

Java I think. The semantic model for C# is closer, and ObjectiveC for iPhone apparently is not garbage collected. You will probably miss some of the features of C#, but most people get over it.

Your choice of language will depend on your motives. If you intend to write commercial software that you want to sell, it's probably best to go for Objective-C and aim at the iPhone/iPod Touch/iPad. Objective-C is a steeper learning curve for a C# programmer than Java but that is as nothing compared with actually thinking up an app that people will want to buy and getting it to commercial quality. And people who own iDevices are still more numerous than people with Android devices and they probably have more expectation of having to pay for apps.
If you are doing it as a hobby then you will want to choose whichever platform your current smartphone/tablet or whatever supports. You are going to be the primary user of your apps. It makes sense to develop apps that you can use. Another consideration, if you are a hobbyist: to develop an iPhone app you need an Intel Macintosh and a $99 Apple electronic certificate to deploy apps to an iPhone even for testing.
The actual language is a relatively minor consideration. A reasonably competent programmer can pick up Objective-C in a couple of weeks. The frameworks will take a little longer, but if you are doing it as a learning experience, it will be a more rewarding experience than learning Java which is nearly the same as C# by comparison.

I have a co-worker who made an attempt to learn Objective C to do I-phone development. We are both .Net developers working mostly in C#. He had a very long learning curve and finally abandoned trying to learn Objective C not only because of the language barrier but also because of the setup. Coming from a C# background, expect a long haul getting your arms around Objective C. Java on the other hand is more like C# and might be better to start with. I am in the same boat as you and actually decided on Windows Phone 7 development first because it is C#. I would go after the droid market next as I think it would be easier to learn.

I know this has been said before, I figured I would point out a fact, C# came about because of the law suit surrouding Microsoft's Java Virtual Machine. I would describe C# as the son of Java and C++, at least in early versions. C# 4.0 has added features neither of them have, its really matured into its own language.
So if you come from a C# background then you should be able to pick up Java effortlessly. Of course Objective-C is C++ on crack, so it should still be possible, what you will miss is Visual Studio and all the features it brings. The reason C# is so easy to develop for is all the features in Visual Studio and most of the features of the language are supported.

As you can see, C# is partially based on Java, so that step would be a lot easier.
I'm also familiar with Java, C# and ObjC and started out with C#, then did Java and now use Objective-C..
And the C# -> Java part was because my education did it that way.. ;-)
And because WEBAPPS are a thing that is HOT right now.. i would say.. Java is a safer choice, because you could base a webapp on that.. although ObjC might also have those possibilities, i just don't know about it..

I switched from C# to Java because I needed to code a lot of systems integration. C# was just not powerful enough / limited to .NET systems. I agree that LINQ is a nice feature, and that generics in C# are a lot more straightforward, but if you start looking at the whole Java ecosystem, I guess these are just minor losses.
Just to sum up some great things you get when switching to Java: Eclipse IDE, maven build system, Spring dependency injection and aspect oriented programming framework + OSGi, GlassFish application server, Grizzly, Jetty, Hadoop, the apache commons libraries, ... . All these things come in Java, and are very useful when you start programming services.
I don't know about Objective-C
Hope this helps,
J.

Have you considered using MonoTouch?

MonoTouch, the future of MonoTouch and whether I should use it for iPhone apps (instead of objective-C)

I've decided to start writing an iPhone app and coming from a c# background, I thought I'd start developing it with mono.
Though this question may be subjective, I'd love some guidance from you.
Is it safe to develop my app using this technology, or should I buy some books and start learning objective C?
I know Adobe were going to release a feature that allows you to build iPhone apps using Flash CS5, but this didn't last long.
I appreciate your feedback.
Marko

Monotouch is doing a great job of keeping up to date (usually within 24 hours of api updates) so just saying you have no idea about xyz but you know abc is much better than it is a bit silly. Monotouch has some serious advantages over obj c - for instance obj c has only been updated something like twice in the last twenty years!! expect good XML, regex, Http support? Think again. Linq in Obj c? never. Good OS community? Not likely. There's plenty of reasons to use MT, aside from C# being a far superior language. Being able to re-use a good percentage of your code in MonoDroid is one. Though there is word that apple are creating a new language - I'm not holding out too much hope for it. We'll see I guess.
I learned Obj C before getting into MT and the reason I went with MT is that using Obj C is like stepping back into the 90s. It just doesn't have any modern language features and is too far behind the curve. Create your bleeding edge apps with their archaic langauge? Thanks but no thanks.

None of us except people who work very closely with the OS and the App store policy in Apple would know whether it is "safe" to develop apps using this technology. Apple can say no anytime in the future, but we don't know. What we know is that all the compiled code has to be in C, C++, or Obj-C. However there's one catch: In some cases you can run interpreted languages.
If I were you, I'd go with Objective-C. We know that Apple supports it fully, it's been in there for almost 20 years. It's not that hard to learn since you know C#. I came from C++/C and it took me about a month or so to learn half of the frameworks. There are many other frameworks which I didn't learn because they're not applicable in my apps (such as accelerators, GPS, OpenGL ES, etc). You probably can get away with this too.
Once again, there's also another way: build it with HTML5. However that way you'd have to consider what your app'll do when it's opened with Safari desktop, Firefox, IE, etc.

The iPhone dev agreement is pretty clear that C# is not an accepted technology for developing iPhone apps. Regardless, Monotouch apps have still been accepted to the app store to date without any problems. My suggestion is to keep in touch with the Monotouch forums to see what their stance is on this issue and make your decision based on that. The long term safe bet is to go learn Objective-C.

Recently Apple changed the clause relating to the third party development tools now stating that if you have prior approval you can use them. I haven't seen any official word that Mono will be allowed though.
If you are coming from a c# background I would highly recommend learning Obj-C because it always helps knowing another language and you could pick it up reasonably easily. Have a look at the stanford University iPhone lectures, they were the best resource when I was learning.
Although I haven't personally used C# or Mono, the iOS SDK once you get to know it has some really great work behind it making it both easy and powerful once you get used to it and I would be surprised if Mono took advantage of it all.

I think it's important to learn the language the frameworks for your platform of choice were written in. Then you can understand more why the frameworks are the way they are, and often anticipate behavior or API calls just based on knowing what is typical for the language and framework.
On top of that there is now a ton of support for blocks across the API (iOS4 and on only), which may take some time to be incorporated into MonoTouch. Overlay frameworks are always a step behind the base platform so it's nicer to be using the frameworks directly.

It's now been months since the Flash debacle and Monotouch and Unity are still rocking along.
As developers in a .NET shop we're looking at expanding into iOS development. After prototyping some fairly basic stuff in Objective-C, We're 100% committed to using Monotouch, it's worth every penny.

How to decide between MonoTouch and Objective-C? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
After sitting through a session today on Mono at a local .Net event, the use of MonoTouch was 'touched' upon as an alternative for iPhone development. Being very comfortable in C# and .Net, it seems like an appealing option, despite some of the quirkiness of the Mono stack. However, since MonoTouch costs $400, I'm somewhat torn on if this is the way to go for iPhone development.
Anyone have an experience developing with MonoTouch and Objective-C, and if so is developing with MonoTouch that much simpler and quicker than learning Objective-C, and in turn worth the $400?

I've seen this question (and variations on it) a lot lately. What amazes me is how often people respond, but how few answer.
I have my preferences (I enjoy both stacks), but this is where most "answers" start to go wrong. It shouldn't be about what I want (or what anybody else wants).
Here's how I'd go about determining the value of MonoTouch - I can't be objective, obviously, but I think this is pretty zealotry-free:
Is this for fun or business? If you wanted to get into consulting in this area, you could make your $399 back very quickly.
Do you want to learn the platform inside-out, or do you "just" want to write apps for it?
Do you like .Net enough that using a different dev stack would take the fun out of it for you? Again, I like both stacks (Apple and Mono), but for me MonoTouch makes the experience that much more fun. I haven't stopped using Apple's tools, but that's mainly because I really do enjoy both stacks. I love the iPhone, and I love .Net. In that case, for me, MonoTouch was a no-brainer.
Do you feel comfortable working with C? I don't mean Objective-C, but C - it matters because Objective-C is C. It's a nice, fancy, friendly OO version, but if pointers give you the heebie-jeebies, MonoTouch is your friend. And don't listen to the naysayers who think you're a dev wuss if it happens that you don't like pointers (or C, etc.). I used to walk around with a copy of the IBM ROM BIOS Pocket Reference, and when I was writing assembly and forcing my computer into funny video modes and writing my own font rendering bits for them and (admittedly trashy) windowing systems, I didn't think the QuickBasic devs were wusses. I was a QuickBasic dev (in addition to the rest). Never give in to nerd machismo. If you don't like C, and if you don't like pointers, and if you want to stay as far away from manual memory management as possible (and, to be fair, it's not bad at all in ObjC), then... MonoTouch. And don't take any guff for it.
Would you like to target users or businesses? It doesn't matter much to me, but there are still people out there on Edge, and the fact is: you can create a far smaller download package if you use Apple's stack. I've been playing around with MonoTouch, and I have a decent little app going that, once compressed, gets down to about 2.7 MB (when submitting your app for distribution, you zip it - when apps are downloaded from the store, they're zipped - so when figuring out if your app is going to come in under the 10MB OTA limit, zip the sucker first - you WILL be pleasantly surprised with MonoTouch). But, MT happiness aside, half a meg vs. nearly three (for example) is something that might be important to you if you're targeting end users. If you're thinking of enterprise work, a few MB won't matter at all. And, just to be clear - I'm going to be submitting a MT-based app to the store soonishly, and I have no problem whatsoever with the size. Doesn't bother me at all. But if that's something that would concern you, then Apple's stack wins this one.
Doing any XML work? MonoTouch. Period.
String manipulation? Date manipulation? A million other little things we've gotten used to with .Net's everything-AND-the-kitchen-sink frameworks? MonoTouch.
Web services? MonoTouch.
Syntactically, they both have their advantages. Objective-C tends to be more verbose where you have to write it. You'll find yourself writing code with C# you wouldn't have to write with ObjC, but it goes both ways. This particular topic could fill a book. I prefer C# syntax, but after getting over my initial this-is-otherworldly reaction to Objective-C, I've learned to enjoy it quite a bit. I make fun of it a bit in talks (it is weird for devs who're used to C#/Java/etc.), but the truth is that I have an Objective-C shaped spot in my heart that makes me happy.
Do you plan to use Interface Builder? Because, even in this early version, I find myself doing far less work to build my UIs with IB and then using them in code. It feels like entire steps are missing from the Objective-C/IB way of doing things, and I'm pretty sure it's because entire steps are missing from the Objective-C/IB way of doing things. So far, and I don't think I've sufficiently tested, but so far, MonoTouch is the winner here for how much less work you have to do.
Do you think it's fun to learn new languages and platforms? If so, the iPhone has a lot to offer, and Apple's stack will likely get you out of your comfort-zone - which, for some devs, is fun (Hi - I'm one of those devs - I joke about it and give Apple a hard time, but I've had a lot of fun learning iPhone development through Apple's tools).
There are so many things to consider. Value is so abstract. If we're talking about cost and whether it's worth it, the answer comes down to my first bullet item: if this is for business, and if you can get the work, you'll make your money right back.
So... that's about as objective as I can be. This is a short list of what you might ask yourself, but it's a starting point.
Personally (let's drop the objectivity for a moment), I love and use both. And I'm glad I learned the Apple stack first. It was easier for me to get up and running with MonoTouch when I already knew my way around Apple's world. As others have said, you're still going to be working with CocoaTouch - it's just going to be in a .Net-ized environment.
But there's more than that. The people who haven't used MonoTouch tend to stop there - "It's a wrapper blah blah blah" - that's not MonoTouch.
MonoTouch gives you access to what CocoaTouch has to offer while also giving you access to what (a subset of) .Net has to offer, an IDE some people feel more comfortable with (I'm one of them), better integration with Interface Builder, and although you don't get to completely forget about memory-management, you get a nice degree of leeway.
If you aren't sure, grab Apple's stack (it's free), and grab the MonoTouch eval stack (it's free). Until you join Apple's dev program, both will only run against the simulator, but that's enough to help you figure out if you vastly prefer one to the other, and possible whether MonoTouch is, for you, worth the $399.
And don't listen to the zealots - they tend to be the ones who haven't used the technology they're railing against :)

There is a lot of hearsay in this post from developers that have not tried MonoTouch and Objective-C. It seems to be mostly be Objective-C developers that have never tried MonoTouch.
I am obviously biased, but you can check out what the MonoTouch community has been up to in:
http://xamarin.com
There you will find several articles from developers that have developed in both Objective-C and C#.

So, my answer to a previous similar question is to learn Objective-C. (Also, don't forget about debugging support)
This will probably offend some but to
be honest, if you are going to do any
serious development, you should learn
Objective-C. Not knowing Objective-C
in iPhone development will just be a
hindrance. You won't be able to
understand many examples; you have to
deal with the quirks of Mono whereas
if you had a working knowledge of
Objective-C you could get a lot more
out of the platform documentation.
Personally, I don't understand the
position that says increasing the
amount of information you need in
favor of using Mono over the
platform's native language. It seems
somewhat counterproductive to me. I
think if this is a very expensive
proposition (learning a new language)
then it may be worthwhile spending
some time on fundamental programming
concepts so that learning new
languages is a fairly cheap
proposition.
Another user also wrote this:
Monotouch is easier for you now. But harder later.
For example, what happens when new seeds come out you need to test against but break MonoTouch for some reason?
By sticking with Mono, any time you are looking up resources for frameworks you have to translate mentally into how you are going to use them with Mono. Your app binaries will be larger, your development time not that much faster after a few months into Objective-C, and other app developers will have that much more of an advantage over you because they are using the native platform.
Another consideration is that you are looking to use C# because you are more familiar with the language than Objective-C. But the vast majority of the learning curve for the iPhone is not Objective-C, it is the frameworks - which you will have to call into with C# as well.
For any platform, you should use the platform that directly expresses the design philosophy of that platform - on the iPhone, that is Objective-C. Think about this from the reverse angle, if a Linux developer used to programming in GTK wanted to write Windows apps would you seriously recommend that they not use C# and stick to GTK because it was "easier" for them to do so?

Using Mono is not a crutch. There are many things that it adds to the iPhone OS. LINQ, WCF, sharable code between a Silverlight app, an ASP.NET page, a WPF app, a Windows Form app, and there's also mono for Android and it will work for Windows Mobile as well.
So, you can spend a bunch of time writing Objective-C (You'll see from many studies where the exact same sample code in C# is significantly less to write than OC) and then DUPLICATE it all for other platforms. For me, I chose MonoTouch because the Cloud App I'm writing will have many interfaces, the iPhone being only one of them. Having WCF data streaming from the cloud to MonoTouch app is insanely simple. I have core libraries that are shared among the various platforms and then only need to write a simple presentation layer for the iPhone/WinMobile/Android/SilverLight/WPF/ASP.NET deployments. Recreating it all in Objective-C would be an enormous waste of time both for initial dev and maintenance as the product continues to move forward since all functionality would have to be replicated rather than reused.
The people who are insulting MonoTouch or insinuating that users of it need a crutch are lacking the Big Picture of what it means to have the .NET framework at your fingertips and maybe don't understand proper separation of logic from presentation done in a way that can be reused across platforms and devices.
Objective-C is interesting and very different from many common languages. I like a challenge and learning different approaches... but not when doing so impedes my progress or creates unnecessary re-coding. There are some really great things about the iPhone SDK framework, but all that greatness is fully supported with MonoTouch and cuts out all the manual memory management, reduces the amount of code required to perform the same tasks, allows me to reuse my assemblies, and keeps my options open to be able to move to other devices and platforms.

I switched. Monotouch let's me write apps at least 3-4 times as fast (4 apps per month compared to my old 1 per month in Obj C)
Lots less typing.
Just my experience.

If this is the only iPhone app you will ever develop, and you also have zero interest in developing Mac applications, ever, then MonoTouch is probably worth the cost.
If you think you'll ever develop more iPhone apps, or will ever want to do some Mac native development, it's probably worth it to learn Objective-C and the associated frameworks. Plus, if you're the type of programmer that enjoys learning new things, it's a fun new paradigm to study.

Personally I think you'll have a better time just learning Objective-C.
In short:
"Learning Objective-C" is not a daunting as you might think, you may even enjoy it after just the first few weeks
You are already familiar with the "C style" syntax with lots of *&(){}; everywhere
Apple has done a very good job of documenting things
You'll be interacting with the iPhone the way Apple intended, which means you'll get the benefits directly from the source not through some filter.
I have found that the projects like Unity and MonoTouch are supposed to "save you time" but ultimately you'll need to learn their domain specific language anyway and will have to side-step things at times. All that is probably going to take you just as long as it would to learn the language you were trying to avoid learning (in calendar time). In the end you didn't save any time and you are tightly coupled to some product.
EDIT: I never meant to imply anything negative about .NET I happen to be a big fan of it. My point is that adding more layers of complexity just because you aren't yet comfortable with the quirky objc bracket notation doesn't really make much sense to me.
2019 update: It's 7 years later. I still feel the same way if not more so. Sure, 'domain specific language' may have been the wrong term to use, but I still believe it's much better to write directly for the platform you are working with and avoid compatibility layers and abstractions as much as possible. If you are worried about code reuse and re-work, generally speaking any functionality your cross platform app needs to perform can probably be accomplished with modern web technologies.

To add to what others have already said (well!): my feeling is that you're basically doubling the number of bugs you have to worry about, adding the ones in MonoTouch to the ones already in iPhone OS. Updating for new OS versions will be even more painful than normal. Yuck, all around.
The only compelling case I can see for MonoTouch is organizations that have lots and lots of C# programmers and C# code lying around that they must leverage on iPhone. (The sort of shop that won't even blink at $3500.)
But for anyone starting out from scratch, I really can't see it as worthwhile or wise.

Three words: Linq to SQL
Yes it is well worth the $.

Something I'd like to add, even though there's an accepted answer - who is to say that Apple won't just reject apps that have signs of being built with Mono Touch?

I would invest the time in Objective-C mainly because of all the help you can get from sites like this. One of the strength's of Objective-C is that you can use C and C++ code, and there is a lot of projects out there that are well tested.
Another thing is that you're code (language of choice) will be supported by apple. What it iOS 5.x for instance removes the support for a third party solution like MonoTouch? What will you tell your customers then?
Maybe its better to use a platform independent solution like HTML5 if you're not entire ready to move to Objective-C?

I've been using MonoTouch for a few months now, I ported my half finished app from ObjectiveC so I could support Android at some point in the future.
Here's my experience:
Bad bits:
Xamarin Studio. Indie developers such as myself are forced into using Xamarin Studio. It is getting better every week, the developers are very active on the forums identifying and fixing bugs, but it's still very slow, frequently hangs, has a lot of bugs and debugging is pretty slow also.
Build times. Building my large (linked) app to debug on a device can take a few minutes, this is compared to XCode which deploys almost immediately. Building for the simulator (non-linked) is a bit quicker.
MonoTouch issues. I've experienced memory leak issues caused by the event handling, and have had to put in some pretty ugly workarounds to prevent the leaks, such as attaching and detaching events when entering and leaving views. The Xamarin developers are actively looking into issues like this.
3rd party libraries. I've spent quite a time converting/binding ObjectiveC libraries to use in my app, although this is getting better with automated software such as Objective Sharpie.
Larger binaries. This doesn't really bother me but thought I'd mention it. IMO a couple of extra Mb is nothing these days.
Good bits:
Multi-platform. My friend is happily creating an Android version of my app from my core codebase, we're developing in parallel and are committing to a remote Git repository on Dropbox, it's going well.
.Net. Working in C# .Net is much nicer than Objective C IMO.
MonoTouch. Pretty much everything in iOS is mirrored in .Net and it's fairly straight forward to get things working.
Xamarin. You can see that these guys are really working to improve everything, making development smoother and easier.
I definitely recommend Xamarin for cross platform development, especially if you have the money to use the Business or Enterprise editions that work with Visual Studio.
If you're solely creating an iPhone app that will never be needed on another platform, and you're an Indie developer, I'd stick with XCode and Objective C for now.

As someone with experience with both C# as well as Objective-C, I'd say for most people Xamarin will be well worth the money.
C# is a really good designed language and the C# API's are good designed as well. Of course the Cocoa Touch API's (including UIKit) have great design as well, yet the language could be improved in several ways. When writing in C# you will likely be more productive compared to writing the same code in Objective-C. This is due to several reasons, but some reasons would be:
C# has type inference. Type inference makes writing code quicker, since you don't have to "know" the type on the left-hand side of an assignment. It also makes refactoring easier and more saver.
C# has generics, which will reduce errors compared to equivalent Objective-C code (though there are some work-arounds in Objective-C, in most situations developers will avoid them).
Recently Xamarin added support for Async / Await, which makes writing asynchronous code very easy.
You'll be able to reuse part of the code base on iOS, Android and Windows Phone.
MonoTouch largely implements the CocoaTouch API's in a very straightforward way. E.g.: if you've got experience with CocoaTouch, you'll know where to find classes for controls in MonoTouch (MonoTouch.UIKit contains classes for UIButton, UIView, UINavigationController, etc..., likewise MonoTouch.Foundation got classes for NSString, NSData, etc...).
Xamarin will give users a native experience, unlike solutions like PhoneGap or Titanium.
Now Objective-C has some advantages over C#, but in most situations writing apps in C# will generally result in less develop time and cleaner code and less work to port the same app to other platforms. One notable exception might be high-performance games that rely on OpenGL.

The cost of the MonoTouch library is entirely beside the point. The reason you shouldn't use Mono for your iPhone apps, is that it is a crutch. If you can't be bothered to learn the native tools, then I have no reason to believe that your product is worth downloading.
Edit: 4/14/2010 Applications written with MonoTouch aren't eligible for the iTunes Store. This is as it should be. Apple saw plenty of shallow ports on the Mac, using cross-platform toolkits like Qt, or Adobe's own partial re-implementation of the System 7 toolbox, and the long and short of it is they're just not good enough.

Developing on Apple (new platform)

Coming from a Microsoft development backgroup I am a bit confused as to what development languages/environments are available on an Mac. Are there any C# like languages to develop with on the Mac other than Java that I should also consider? What do MS to OSX converts prefer and why? I am after a business level programming strategy and not gaming or graphics so application performance is not the overall driver for my choice of platform.

Objective-C with the Cocoa API is the way to go. Once you have those down, there's also bridges between Ruby and Python to the Cocoa API. I'd highly recommend initially learning the Cocoa API with Objective-C first, though.

I also just bought a Mac and come from a .NET development background. I tried a bunch of different languages and environments. If you're going to write OS X desktop software, you're going to need to use Cocoa and Interface Builder. IB doesn't have a Windows counterpart because it's so heavily tied into Cocoa. This means you're going to need to learn Cocoa simultaneously, and it's not easy to do by looking at code.
Objective-C is the native language of the Mac and it's not as refined as C#. It takes a while before you can read it fluently because calling functions looks different. Using Python or Ruby instead of Objective-C only adds a layer of complexity until you learn Cocoa, but it seems quite viable after that. C# via Mono works fine, but I don't think the whole Cocoa# bridge is implemented. The C# tools are a lot lower quality than Visual Studio, and MonoDevelop is extremely ugly on the Mac. I decided that if I want to go this route then I need to learn Objective-C, but went a different direction.
If you're writing a web site then you have a lot more flexibility. The entire Python and Ruby cultures are available, although there are some hiccups with installing some Python libraries. This is the route I took because I had some basic Python experience and the skills are almost 100% compatible with Linux. iTerm is a better client than Terminal. I didn't like most of the code editors I tried, and started with Smultron which isn't much more than a very competent text editor with syntax highlighting. There are definitely tons of options.
No matter how you approach it, you're going to spend a lot of time learning. I have constantly stumbled over Python syntax but I'm finally getting good at it. The SQLAlchemy (Python ORM) docs almost always have an open browser window. I also bit the bullet and started using Vim (MacVim specifically), which is actually a fun thing to learn because there always seems to be another command that does exactly what you want. (For example, I got tired of going to a line, hitting $ to go to the end, hitting a to append, then hit enter to start a new line so I Googled and found out I can just hit o.)

Have a look at the Mono project
Quote from wikipedia
Mono is a project led by Novell (formerly by Ximian) to create an Ecma standard compliant, .NET-compatible set of tools, including among others a C# compiler and a Common Language Runtime. Mono can be run on Linux, BSD, UNIX, Mac OS X, Solaris and Windows operating systems.
But I really recommend go the Cocoa route and get Aaron Hillegass book "Cocoa Programming for Mac OS X"

Objective-C, C, C++, Java, Ruby, Python, Php, ... There are lots of choices of languages/development environments to use, including C# via Mono as #epatel says. I would say that the choice of language depends more on what you are developing than on what platform you are coming from.

Objective-C and Cocoa is the way to go for sure. Quite often devs will make the misconception that Objective-c isn't "as detailed", or "as fine tuned". But I can assure you, it's the power house behind some of the best apps in the business. There is a noticeable learning curve.

On a related note,
Silverlight is a web-based "flash-like" technology supported on Windows and Mac and you can code in most .net languages.

C# is available for OS X, as long as you're willing to use Mono. For non-UI and web stuff it ought to work just fine.
For desktop app development, I use REALbasic. It's syntax and object model are very similar to Visual Basic.
For business-level programming, I'm not sure if Cocoa/Objective-C will be the most productive thing to start with; it's quite different than .NET and/or Java.

I would forget mono, it doesn't work very well. Slow, buggy and system.drawing/forms don't work properly when you distribute.
With c# I would go with monomac. You access all the mac apis but in c#. It's like a half way house. Instead of Forms you use NSWindow and instead of controls you use NSView. Instead of drawing you use graphics context. The downside is the documentation is a bit thin and it costs.