Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have worked some with Cocos2d for iPhone and find it delightful. I am starting another project, and have stumbled across Cocos2d-x, a C++ port. I'm tempted by the notion of being able to (with consideration) build for multiple platforms at once. I'm equally comfortable with Obj-C and C++, and am not looking for comparisons between the two languages unless it's specifically related to working with Cocos2d.
Has anyone worked with both versions of the engine, and can you comment on specific pros and cons of the two? Is Cocos2d-x "finished"? Reliable?
The lure of multi-platform builds are a nightmare in disguise. Any web designer will tell you horror stories of trying to juggle IE with Firefox with Chrome with whatever at the same time. You will not suddenly earn more sales because you were able to launch on Android/iOS/etc on day one. More than likely, your attempts to multi-platform will restrict your app in ways that will kill it on all platforms. Your best bet is to start with one platform, finish that, then build for others. Your end product will thank you.
There are no pros/cons to Cocos2d-x unless you like C++ more than Obj-C.
I would agree that you should focus on developing for a single platform until you have a good solid product out there. However many a developer that does this after the fact realizes how much effort and additional cost is then needed to completely rewrite the game on a new platform. Would a little upfront thought you can minimize the need for rework and thus minimize your cost once you are ready to port your game. Android is too big of a market share to completely ignore it; in my mind Cocos2d-x is the way to go if you like Cocos2d.
I don't know about cocos2d-iphone but I do know about cocos2d-x.
Pros:
cocos2d-x uses C++ (well, not really a pro for some but this is a pro for me)
You can easily deploy to different platforms, assuming you've set it up correctly (see below)
It supports Lua and JavaScript, for an even easier coding
Cons:
cocos2d-x has little to no documentation. You would rely on the test projects and the API Reference. Thank god there are people like Nat Weiss who made learning easily available to users. (http://paralaxer.com/cocos2d-x-book/)
Setting up your project to work on every platform is a hassle. You'd have to be good at multiple IDEs as well as command line/terminal commands
Most of the scripts that come with the library to create new projects are not multi-platform, meaning, you still have to set it up individually for all platforms
Integrating third-party SDKs like Facebook, ads, and other stuff takes a lot of time since you'd have to implement them for every platform you are targetting
I am developing with cocos2d-x for iphone and it is working just fine for me. Only issue you may find is that the api is always slightly behind the cocos2d for iphone version. However api itself is reliable and a facsimile in most respects to the original.
If you're serious about porting to other platform even though you will try to succeed on a single platform first, cocos2d-x is the way to go, because you will not need to rewrite the gist of your code in some other language later (ie port from c++ to objc or from objc to c++).
I have worked with both Cocos2d and Cocos2d-X for iPhone development only (so far). I worked with Cocos2d for about 1.5 years and have moved on to Cocos2d-x in the last six months or so. At first, I was unwilling to move into Cocos2d-x because, in my opinion, it was still maturing. Coco2d 2.0 had come out with a lot of changes and I knew it was well deployed and tested. Coco2d-x seemed like it was still in flux. This has changed and I have decided to use Cocos2d-x for the duration, as long as it continues to be supported.
Both frameworks appear to work as advertised, in general, and give good performance for what I am working on (you can see some examples here).
I am comfortable with working in both the Object-C and C++ world. I don't know if I will ever port my "stuff" to Android, but it is nice to have the option.
However, the BIG deciding factor for me was reusability. I build lots of components and widgets that I reuse in other projects. If I developed for iOS only, Objective-C would be the way to go. But I work mostly in C++ and I don't want to have to recode all the ideas from one language to another every time I want to bring a tested tool out of the tool box.
I think this is going to ring true for any framework you choose to use for your development. If you have the choice, go with the option that will give you the best bang for your buck today, and down the road.
I am currently working on cocos2d-x and I am very happy with it. My advise would be to start the project on one Platform (I prefer IOS). And when you have successfully launched on one platform, start on another.
If your game becomes successful, at the end you have to launch on another platform too. So its best to plan ahead.
I would stick with Cocos2D-iphone. Focus on the product from the bigger community with a lot more resources. When you are ready to port, then use apportable to compile your app for android when it's done.
Related
if mono touch is available than why we should use mac environment(sdk,xcode+Interface Builder)?
what are the disadvantage of monotouch compare to xcode?
I always prefer working in the language that is most philosophically aligned with the platform I am developing for.
That is to say, the frameworks the whole platform is built around were written for and in Objective-C. As such, if you are working in Objective-C yourself for a while you understand why things are built the way they are, and can also anticipate calls that might exist or behaviors.
Just as I would not develop for Windows Phone 7 in anything but Silverlight, I would not program the iPhone in anything but Objective-C in order to get the most out of the platform. New language? That's a benefit as people should learn new languages now and then anyway. And it's not like it saves you that much time to use a language you already know since a large majority of your time will be spent learning the frameworks (which MonoTouch lets you call into).
I feel like this needs an answer from the MT camp, too.
Why eat fish, if you can have meat? Why speak German, if English is understood? Why watch CNN if there is FOX? Why vote vote for the Republicans if there are the Democrats? Why...? And so on.
It is your choice! If you have worked with C# for a long time and want to have quick results on iOS, go MonoTouch. Especially if you have a collection of APIs or methods you can reuse, MT is the way to go. If you want to learn a new language (ObjC), go for it. Even if you use MT in the end, knowing ObjC is somehow crucial because it helps you understand why things work as they do.
Hello here is my personal opinion,
I've also been on .Net world for a while, when iPhone launched the ability to create native apps, it called my whole attention and i really tried to learn objc, i took 2 books and started trying and trying and trying like for a month and then I left iPHone programming due to you had to make tons of things than on .NET was a line away for example the GC.
When Miguel de Icaza launched MonoTouch i gave it a try and i realized that most of my previously done code was fully funcional (i've always tried to separate ui code from business code) and this is really the point of .NET on the iPhone, to bring most of your already done business logic to the device.
Also on objc you wont find anything like LINQ or var keyword, consuming web services on MonoTouch its just a few clicks away etc.
If you want to target the Android platform there is also MonoDroid (monodroid.net) wich its coming out later this year the stable release, you can give it a try right now on the beta state. Also if you want to target Mac OSX there is MonoMac. So you can share class libs between all this 3 platforms (also al mono/.net supported ones) without hassle not to mention it will work on windows too and viceversa (when possible) (Also dont forget about WP7).
The only thing you will need to worry about its the UI but most of your business logic should work. here is a complete list of .NET Assemblies supported in MonoTouch http://monotouch.net/Documentation/Assemblies and also MonoTouch exposes a C#/CIL binding to all the CocoaTouch APIs.
Also the support of the MonoTouch team is awesome you can just get on IRC ans ask a question and it will be answered right away, mailing list too :)
I really enjoy MonoTouch, i know that no language is perfect for all tasks, and Objective-C is no exception.
Every example, tutorial, and piece of documentation will be written in Objective-C, and mono will just be calling into Objective-C code under the hood. If you really feel like C# is worth mentally translating everything, and adding an extra layer in your code, go for it I guess.
As a C# developer, I've found Objective-C to be horribly painful to become confident with. It's taken about two months, and two excellent resources to get to this stage.
Get your Visa card out, you'll need to spend a total of $54.
1. The free Stanford "Developing apps for iOS" lectures.
Pure brilliance, and it makes learning Objective-C very clear.
http://itunes.apple.com/us/itunes-u/developing-apps-for-ios-sd/id395631522
2. The iOS Apprentice series.
This is where you'll need to cough up the $54. It teaches you, step by step, how to program in Objective-C, and the apps you build are actually pretty impressive. Part 1 (of the 4 parts) is completely free, so you can give it a go before parting with any cash.
http://www.raywenderlich.com/store/ios-apprentice
I've yet to find any iOS books which match the clarity and friendliness of these two resources.
Finally, don't buy any books unless they specifically say that they're for iOS5 and XCode 4. This latest version of XCode is simply too different to make them useful.
Disclaimer: I don't work for any of the resources mentioned in this thread !
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 9 years ago.
Improve this question
I want to build a mobile/tablet application whose core feature will be taking pictures with the camera , viewing pictures and receiving notifications. Also I want to target iphone, ipad and android platforms.
Titanium appcelerator piqued my interest because of its cross platform appeal. However I am concerned because I've read mixed reviews on SO and other sites. The things that worry me are:
Subpar android support
Camera support not fully capable (e.g ios 4.1 HDR capability)
Camera support buggy
The nightmare scenario for me would be to invest time in titanium only to discover later on that its a major PITA and drop it and go "native"
Please share your thoughts and experiences.
I chose Titanium for a serious application, although one that does not use the camera. I think there are a variety of things that could play into your decision...
If your app intends to do "fancy" stuff with the camera, or some real heavy image processing and so on, you're likely better off going native. If on the other hand, you just want to have it take pictures, and then those will be used as-is, or sent to a server, or what not, then Titanium should work just fine. Titanium does have some processing and image manipulation things, but as others have said, if you really want to take advantage of the device's hardware, you probably want to go full native.
It should also be noted, and Appcelerator says this as well, that with a Titanium app, you won't just write a single app that works as-is on all devices. You will need to taylor the UI to each device (or class of device, i.e. iPhone, Android), because they have different UI's, and different standard UI flows and so on.
But, one of the potential advantages to Titanium is if you don't know Objective-C and/or Java, and you do know JavaScript (and in my case, I'm actually using Coffeescript :). Or, if you would enjoy your work much more writing JS than ObjC/Java. This was one of the main reasons for me. I have done some ObjC dev in the past, and don't even mind it, but this project I'm doing is on a very very aggressive schedule, and it was just going to be far more effective for me to use Titanium. I was able to get set up and build an app extremely quickly, and I am not spending any time having to become more deeply familiar with the programming language I'm using, memory management bits (you can't fully ignore this with Titanium, but essentially they're doing it for you). Based on the folks I've talked to, and how much time they spend with memory management, Interface Builder issues (this is mostly the ease of forgetting to setup connections or hook various things up, IB is actually a pretty great tool), and so on, I'm quite glad I'm using Titanium.
While I expect to do an Android version at some point, it's not a priority. But, I'm glad to know that a large chunk of my app code will be re-usable, tested, etc. and that I'll wind up mostly just building/revamping the UI for Android, not rewriting networking code, data management, and so on. Android support will be much better (supposedly) in Titanium 1.5, but you may want to wait for that release to evaluate Android if that's a priority.
Finally, Titanium does have a "module" system, that allows you to wrap native code, exposing it as a JavaScript interface in Titanium. We are about to leverage this to integrate a third party library, and at least for what we need, it looks very easy to use, and has given me a little more confidence that if some particular native feature we need access to comes up, that we'd have a decent chance of integrating that while still using Titanium, but I think it would depend on what the particular native functionality was.
Good luck and enjoy building a mobile app, it's pretty fun!
We have been using Titanium in one of our projects for around 2 months, and frankly speaking our experience with Titanium is too bad.
As per my opinion, below are some major drawbacks of Titanium:
1) First thing is you will not get debugging support at all (We can understand how debugging require in any of the project and in any of the technologies).
2) Titanium is NOT fully supporting all the features of Android/iPhone; beyond some level it will not give you support.
3) Comparing with Android/iPhone SDK, developers will get very less amount of help from the internet and API library (Titanium provides the API library help file).
These are the general issues that end developers face while dealing with Titanium and I suppose sometimes it will be tedious and frustrating work for them.
If the functionality of your application is somewhat like displaying data from the web (like many news, media type apps) then Titanium is the suitable option; otherwise not.
The Android support is not near as good as it is for the iPhone. If you were to just say iPhone I would say you would have luck using Titanium. However, I think trying to build one code base in Appcelerator and also use in your Android environment may not be the best experience.
That said, IMO doing Android / Java code is much easier than doing Objective C / iPhone work.
So worst case I would consider using Titanium for your iPhone version & do Android in Java.
You can give it a shot doing them both in Titanium, but worst case code the Java version.
I just hate objective C and the 'native' Apple development environment so much.
I would recommend against using a cross-platform toolkit when interacting with device hardware is one of the key requirements of your application. I haven't worked with Titanium before, but I find it hard to believe that they will give you the same level of hardware access that you get with native frameworks.
In particular, iOS 4.0 added a mess of new capabilities regarding the camera, including live video frame processing through AVFoundation, and I find it hard to believe that a third-party framework will keep up as these platforms advance. To be honest, it's pretty easy to write an application that interacts with the camera on the iPhone nowadays (count the number of them on the App Store as an indicator of this). I wrote a live camera frame processing application in about six hours the other day.
I can't speak for Android, but I imagine dealing with cameras is fairly trivial using the native APIs there as well.
You're also going to find performance testing and debugging your application to be far easier using the native tools than those supplied through a third party. In particular, Apple's Instruments is an extremely powerful, yet easy to work with, application for tracking down CPU and memory issues within your application.
There's also the community aspect. You'll find far, far more people working on Android and Cocoa Touch than on Titanium (just look at the numbers of questions in the various tags on Stack Overflow to see that). This means many more tutorials and a whole lot more sample code that you can use.
The time you'll spend getting your iPhone and Android build environments set up, and submitting to both stores, will be the same no matter if you go with a native environment or with Titanium.
In the end, even with learning both platforms, I think you'll come out ahead by avoiding a cross-platform solution. Trust me, I've tried to do cross-platform development before for other projects and ended up with lowest-common-denominator products that took much longer to write.
I've developed an Appcelerator-based camera application and was very pleased with it. I think some of the negative reviews come from the fact that it's a bit hard to get set up (more due to Apple's crazy developer registration process).
Once I got started, it was easy to do things like overlays on top of the camera screen. I was really expecting difficulty with that part, but it worked well.
I have spoken with the Appcelerator team in the past, and they are a great group to work with. I've seen them be responsive to other user issues, and I'd trust that if I ran across a real bug, they would address it quickly.
A little late, but my two cents...
I honestly believe you can very quickly prototype an application with Titanium Appcelerator and focus on the critical feature sets to determine if it is the appropriate tool for you.
All developers have there opinions and experience(s) which influence there comments; developers have different ways of learning and different levels of productivity... In the end, it comes down to how are you most productive with the tools available to you.
Since you are stating from the start that you want to deliver a solution an multiple platforms, I think it would be a poor decision on your part to not even spend a week or two investigating cross-platform frameworks and then making the decision based on your personal experience.
There is Titanium Appcelerator and there is also PhoneGap, where PhoneGap might help you is that there is the ability to extend/enhance the underlying framework through writing plugins (I wrote one for iphone ) and there is an android one on my blog also... this can fill missing gaps for you when you move across platforms.
Also since the UI in a phone gap solution is HTML5 Webkit based, it can give you a consistent look and feel across you devices if you like. Frameworks like jQTouch and JQuery Mobile are being used for UX with PhoneGap Application
I reviewed negative feedback for Titanium Appcelerator but I tottaly agree with Aaron Saunders that if you use PhongeGap Development is support HTML5 which can getting easy to make apps for iPhone, iPad and Android mobile.
Has anyone highlighted the cost off titanium.
I was contacted by them today and if you are more than a one man band you have to sign up for a partnership program else you are held liable for breech of contract if you release the app.
The partnership program is £5000 which is far to much for us as a start up company when it's our first application, we are currently looking for a different option now.
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
[2015 update: I think it's safe to say that Flash is rapidly dying. Don't go there. Gotta say though, during its brief moment to shine, Flex was actually a really lovely datavis technique.]
I'm interested in developing for the iPad and iPhone, but I'd prefer not to learn Apple's whole development stack (and good golly, I sure don't want to go back to manual memory management). Oh, sure, I could learn it, but I don't have that level of commitment to the environment at this point. I've got professional experience with Flex already, so I'm intrigued by Adobe's move to make Flash/Flex compile to the iPhone and iPad. My question is: how promising of a development path will Adobe's Slider be? Are we likely to see Slider publicly available in a reasonable timeframe (Adobe: "An early mobile branch of the Flex framework is expected to be available in 2010")? Are we likely to see reasonable performance? Are there development hurdles that haven't become clear yet? Heck, is it all just vaporware? There's pretty limited information available so far, as far as I've seen, but I'm interested in people's predictions, even if they're speculative.
Hopefully you'll see some info on Slider soon that will give you a better sense of the timeframe. Flex 4 will be released soon and once that happens you should start to hear more concrete info about Slider.
One thing to keep in mind is that Slider will be based on the Flex 4 architecture. To give you an idea of how that performs you can check out James Ward's blog post - http://www.jamesward.com/2010/02/21/flex-performance-on-mobile-devices/ - he's got a couple of videos that show a Flex 4 list running on a Nexus One.
This isn't iPad/iPhone, and Flex is NOT something Adobe recommends for mobile, but this basic example works pretty well. And it should give you an idea of how Slider might look/behave.
=Ryan
ryan#adobe.com
Interestingly, Apple's new developer agreement calls into question whether apps built with Flash/Flex will be allowed:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Adobe's cross-compilation tech is not vaporware (for Flash, anyways-- haven't seen as much re: Flex). And they would be unlikely to invest so much in it if they thought it would get torpedoed on day one. That said, you must draw your own conclusions about your long-term reliance on it, and your interest in building on a non-native toolchain, both in terms of what you can get out of the environment, and the support channels you'll need to use (e.g. not Apple) when stuff doesn't work.
Some people seem to be successfully using Mono touch, which shares (some) similarities.
There are two issues with this:
Steve Jobs says he isn't going to support Flash on iPhone or iPad.
Adobe's next rev is going to allow you to develop in Flex and port to iPhone app format.
Do the math.
If you want to start iPhone, iPa or Mac OSX development, I'd suggest learning Objective-C. It'll probably take less time than waiting for (official) Flash support on those devices ...
Take it the other way around, would you use Objective-C to develop a Flash or a Flex app?
Flex can now compile iOS applications (and so run on the ipad and iphone)
http://gregsramblings.com/2011/06/20/finally-its-here-flex-on-ios-android-and-blackberry-playbook/
http://gregsramblings.com/2011/04/26/convincing-developers-that-adobe-flex-rocks-on-android-ios-and-playbook/
I'm new to IPhone development and have to decide on a suitable tool to develop my application in. Since I am know C# / .NET, but not objective C, Mono Touch seems appealing to me. But is it is worth spending the extra $400?
If have tried both, I'd be interested in your opinion.
I just posted about this at www.zouak.com, but in short for me it was a case of divide and conquer. I have years of .NET experience and honestly found learning Objective-C frustrating. Having a new language plus a new set of tools reduced my productivity significantly, also having to deal with manual memory management after years of not (prior to 2001 when I started with .NET I was a Java guy since its inception, so it's been a while) was an extra layer of "been there, don't want to go back."
I've found the MonoTouch toolkit to be very worthwhile, and while I understand some of the objections and concerns, I'm someone for whom leveraging what I know (C#) allowed me to focus on what I didn't know (Interface Builder, the API, etc.). At this point now that I've built up a significant amount of familiarity with the Apple tools I'm nearing a point where if I wanted I could look at taking on Objective-C as a new language, given that I am a lot more comfortable, but for me learning a new language isn't as rewarding an accomplishment for me at this point in my career compared with learning a platform and getting quality applications out the door is. For other folks I know they enjoy delivering "as Apple intended", and I fully respect that. Also, if Apple had a Java toolkit, I would be all over that. But the conceptual distance between C# and Objective-C is more than I'm willing to invest at this point.
That's my 2 cents,
Driss.
Great podcast on this week's dotnetrocks about this.
One HUGE factor that would sway me is the fact that they are currently working on Monodroid and I guess that WinMo 7 will probably be supported through some moonlight magic.
Imagine targetting the top 3 mobile platforms with one language? Sweet....
I've been using MonoTouch for 5 months, and really like it.
Take a look at my answer to a similar question here: MonoTouch - has anyone used this?
I am an iPhone developer, I have tried mono touch, but for me I would say NO, it's not worth the extra 400.
First of all several free frameworks exist that allow you to target multiple platforms at once using different (usually high level) languages, such as PhoneGap, there's even a Flex framework somewhere, without counting Unity3D which actually uses C# and even allows you to deploy on iPhone and Nintendo Wii.
Some of the Cons of using this third party frameworks are:
1- Extra software layer, which obviously increases the possibility of failure. Last year it happened with Unity3D. Somehow the applications developed with it started being rejected by Apple (official Unity announcement here) , Unity guys responded fast, and I think they fixed the issue with Apple in 3 days. But what if 3 days is too much for you, or even worse, what if the external framework that you are using to develop doesn't have that quality of support and the 3 days end up being weeks?... what if your applications got broken with an OS update ?
2- You totally loose Xcode debugging chances (loose the symbols), and you are kinda reduced to printf debug. Of course you can debug in the Mono IDE, but still, Xcode is a powerful beast and all the SDK Betas are delivered to the developers to be used with particular Xcode versions.
3- Binary size tends to be bigger in comparison to native Objective-C applications. ( 6 to 7Mb larger in average ), and remember that if your application is above 20 Mb it can't be downloaded from an iPhone using 3G or Edge, ( which is the most popular way to install apps ). So if that matters to you, it's another issue.
In conclusion:
If you want to use MonoTouch because you don't know Objective-C, go for it, but still I would really recommend you to take a bit of time to learn the Objective-C language and the official Apple API's. Here's a great point of view about this.
I would say no, because the biggest thing to learn about the iPhone SDK is not Objective-C, but the APIs instead. Even if you used Mono Touch, you would have to learn the API for the iPhone.
It never hurts to learn a new programming language.
(However, don't listen to me, because I am using Lua to write my iPhone applications...)
I'm a .NET developer trying to make the leap into objective-c iPhone programming. I created my first app - just a simple portfolio with multiple xibs.
I've just come across MonoTouch which lets you develop iPhone apps in C# or .NET. Has anyone tried this out? I'd be interested to know people opinions on it.
I have been using it for 5 months now, and I have an app developed using it in the App Store ( http://escoz.com/quicklytics ), as well as a few internal projects deployed at a client.
Here's my point of view:
If you're a .NET developer, and want to develop for the iPhone, you'll need to learn two new things: Obj-C and the iPhone SDK. Both things are quite different from .NET, and it can be quite difficult to get going, specially if you have a deadline. In general, you'll end up getting stuff done, but mostly by copying-pasting a lot of random code from the web for months and months. Yeah, you may actually spend the time and learn it properly and not do that, but that will take a lot of time.
Using MonoTouch allows you to totally skip the first problem (obj-c) and helps tremendously with the second (sdk). After a couple of days reading and watching videos online you can already be fairly productive, using things you're familiar.
Yeah, it does cost at least $400.00, and if you're thinking about developing stuff for fun over the weekend, that may be a little expensive, but if you're thinking about writing code for work, this is a no brainer.. The amount of time that it'll save costs a lot more than the $400.00.
Size of apps: the apps will be larger (6-7Mb larger in average): nobody cares about it, honestly.
Speed: while technically it is possible to make obj-c apps that run a little faster than C#, in practice that simply doesn't happen: monotouch is as fast as obj-c for all purposes.
Bugs: not having to deal with memory leaks all the time and having a higher language to develop in is a huge deal.
Even if in the end you want to pick up Obj-C, I would highly recommend you start with MonoTouch and get familiar with the APIs. The demo is available for free and allows you to do everything other than deploying to an iPhone. Only when you know how the API works move to Obj-C (if you still want to do it at the end).
One last point: if you're thinking about porting your apps to other mobile platforms, MonoTouch seems to be the platform to use right now: most of your code can be ported to the Windows Phone SDK, and Apple will release MonoDroid (MonoTouch for Android) in the next 5-6 months.. This really matters to me, maybe it also matters to you.
Tried it, loved it.
Being able to re-use .NET knowledge is a definite plus (even though learning Obj-C is most definitely still encouraged.
The only downside is that the executables are larger than their respective Obj-C counterparts. That...and the cost associated with the license (if you're going to distribute your apps).
I tried it.
If you think you're going to program many programs for iPhone, I think is better to learn Objective-C. But, if you have some big source code or existing programs written in C#, that MonoTouch may be the best solution for you!
Rory Blyth addresses this very point in a very similar question:
Monotouch or Titanium for rapid application development on IPhone?
Our whole dev shop moved from XCode and Objective-C to MonoTouch. Most of the team also have .NET C# skills.
We're about 2/3 more productive in our XMl/database-centric apps + web services . Monotouch has a lot of built in tools for those things.
It's quite expensive, and you still need a Mac.. so if your idea was to stay in Windows and write iPhone apps using Visual Studio, you're out of luck sorry... At $399 as the lowest price, on top of the $99 for a developer license from Apple, I don't think it's worth it unless someone else is paying (eg, a corporation etc). You'd be better off sticking with Objective-C and Xcode, since you've already played with it.