MonoTouch and MonoDroid allow us to write our apps in C# and this is the right solution for our mobile apps and here are the reasons why.

Note: These reasons were ones I provided to a C# shop so some may not be valid for places where the majority of developers are not C# developers.

1. MonoTouch is native. See monotouch is both a wrapper for the native code and the ability to access C# libraries. It is not like flash or html 5, where it is completely different technology. It is just the ability to use native code from C# with an added C# framework.
2. MonoTouch uses the native UI (and MonoDroid does too). So UX’s desire to have a native UI is met by MonoTouch.
3. Many companies already use MonoTouch and MonoDroid: Microsoft, 3M, VMWare, Novartis, Target, Acenture, Cisco, AT&T, AOL, Monster, Cornell University, Raytheon, Intuit, HP, and many more companies.
4. The number of C# language experts we have: All of us
   The number of Objective-C language experts we have: Zero
   With C# everybody can work on the code, not just one or two Objective C engineers.
5. If we use Objective C, we will have a huge ramp up expense and this expense will occur over and over, because every time someone quits, it is more likely that we will have to incur the cost of training a C# developer to become an Objective C developer than it is likely we will hire. As you know, hiring a replacement may or may not happen.
6. Shared C# code. A large portion of our code the code write for SharePoint, iOS, Windows, and Android can be used and unit tested in one place. I have personally experienced this re-use of code at my previous company. We starting an Android app and our project was finished more than three weeks early by using MonoDroid, because we were able to use all the C# code we had already written.
7. C# is a more developed language and is far easer to write code in. For example, to connect to a web service using windows integrated security is just a few lines of code in C# but requires extra libraries and a massive amount of effort in Java or Objective C.
8. Shared Unit Test libraries. Since much of the code is shared, separate unit tests are not needed. Also, the C# unit testing frameworks we are already familiar with can be used and there is no need to ramp up on and implement a new unit testing technology. This is just another cost saving.

I recommended MonoDroid and MonoTouch at LANDesk and I will do the same here. The cost of using Ojbective C is far greater and the time to market is far longer. The SDLC of Objective C will have a greater cost. Choosing it will be a costly.

Since this isn’t my team and since it isn’t my decision, this is the last I am going to say about it.