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 !
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
A recent post by John Gruber notes that the following legalese:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
Has been revised as follows:
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).
And makes the following observation:
My reading of this new language is that cross-compilers, such as the Flash-to-iPhone compiler in Adobe’s upcoming Flash Professional CS5 release, are prohibited. This also bans apps compiled using MonoTouch — a tool that compiles C# and .NET apps to the iPhone.
Does this in fact ban the use of Monotouch for the IPhone?
Update -
This changed recently. MonoTouch should no longer conflict with
the agreement. Any statements below are purely historical!
Yes, it seems pretty clear from their license agreement now that if the original application is written in C# then it would be violating the license:
...Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine...
They even hammer it in a little further:
Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited
Kind of a bummer, MonoTouch and the Flash CS5 -> iPhone converter are very cool.
Update:
Apple has dropped (almost) all technical requirements for languages and libraries for iOS, so MonoTouch is without a doubt a viable solution. See Apple's announcement.
Most people here simply want to take Apple's document by the word and say "yes, its banned". Well, here's my point of view: at this point, nobody really has any idea if MonoTouch is going to be banned or not, and I'll explain why:
The Apple agreement version 3 (not the latest, the one before) clearly states that its illegal to use any other frameworks to develop applications other than the ones provided by Apple:
3.3.2 An Application may not itself install or launch other executable code by any means, including
without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded or used in an Application except for code that is interpreted and run
by Apple's Documented APIs and built-in interpreter(s). http://adcdownload.apple.com/iphone/iphone_sdk_3.2__final/iphone_sdk_agreement.pdf
Even though that's the case (and was actually the case since 2.x, apple doesn't have any problem accepting applications that do exactly that. For example, ALL EA games use Lua scripts, and lots and lots of people use external libraries that are not native to the iPhone. Even when the iPhone has those native APIs, Apple never had a problem accepting applications with different versions of it, like SQLite.
My point is that saying "YES, they'll be banned" right now is simply WAAY too early. The only clear thing at this point is that Apple could in fact use that to ban apps. Just like they accept Apps today that are against some of their rules, they'll probably continuing doing so.
There's also the fact that are hundreds (or probably a few thousands?) of apps in the store currently running Mono, and Apple will need to accept updates for those apps. Major apps with millions of sales were created using Mono (and Lua), and I doubt they would refund every single user.
Lastly, Enterprise applications are deployed to iPhones without Apple's approval, and that's a big market that MonoTouch is on (I myself develop enterprise apps). There's no way at this point that Apple could ban MonoTouch for those applications, and that will probably be enough to keep MonoTouch alive for a long time.
Update:
New changes to sections 3.3.1, 3.3.2 and 3.3.9 have made MonoTouch (and all other cross compilers/languages/etc) perfectly acceptable on the iPhone. See Apple's announcement
Miguel doesn't seem to think so. See the tweet and Miguel's response. Lets not overreact here and say that Monotouch is dead, or stop developing with Monotouch until some clarifications have been made by all parties involved.
That said I would definitely start putting the heat on Apple for such draconian development policies. Things like this, and the nebulous process that is the approval policy of iphone/ipad/touch apps should strike fear into the hearts of developers. What's next, their license stating that the only Ad platform you are allowed to use is iAd? Not allowing the distribution of free apps without iAd? Slowly raising Apple's share of the revenue of app sales? As developers in a locked down eco-system, we are kind of frogs in a pot of hot water, and Apple is slowly turning up the heat. Now is the time to explore other mobile platforms, because as they get better, the main thing holding people to the Apple platform is lack of applications on other platforms.
I spent months of evenings working on ideas for a killer iPhone app in Objective C. My day job is C#. I downloaded MonoTouch C# when it became a viable alternative and have just spent 3 months converting my code to iPhone specific MonoTouch C#. Which stopped me going mad through switching from C#/Objective C.
What do I do now throw it all away and start again or give up!?!
I feel really sorry for the Mono guys. This is plain wrong. It is one thing to stop Adobe who haven't launched their product and have no customers and to stop MonoTouch who do and also have approved product in the AppStore.
Why would anyone want to build a business and invest in Apple when they will take it all away at a moments notice without being answerable or questionable?
Clearly developers and customers of Apple caring for them and their products is a one way street.
I hope Apple gets trounced for this ridiculous policy. Arrogance is not attractive and generally bad for business. This is one of the reasons I haven't started iPhone development.
Most hardware and OS providers are happy to have additional tools and audience to write to their platform. Apple is taking the stance that its (braindead) tools are the only game in town.
The "Big Brother" ad from 1984 is more and more relevant...
EDIT
The way it is written also seems to imply that if I wrote a .net to objective C/apple translator that the code isn't acceptable because the original code was not objective c. That is ludicrous (and unenforceable.)
Unity is also based on Mono and with that being a sizable commercial product I imagine that this is an issue which we've not heard the end of yet.
Banning all apps that are not written in Obj-C/C++ would, in theory ban all Unity games also, of which there are a large number already in the app store.
This question has also been asked over on the Unity Answers site, and their official answer is:
"We just heard about the iPhone OS4.0
and the new Terms-Of-Service. While we
believe we are fully compliant with
these we are right now doing all we
can to get this verified by Apple. As
soon as we know precisely, we will of
course share that info with everybody.
Please hang tight while we get this
sussed out."
Be interesting to see what they get told by Apple.
The thing is, surely saying that an app has to be written in a certain language is a bit of a misnomer, as once the app is compiled down, it's always a native binary regardless how it's been built. My guess is that all they can look for is some kind of signature in the binary to detect what tool it was built with. A flawed approach.
EDIT: There is an interesting overview of the situation on this blog: monotouch now dead in the water what does apples new iphone developer agreement mean
The new license agreement is explicitly clear about that. So YES, it will be banned.
Advice, if you want to really develop for iPhone, try XCode. If you are already familiar with Java or C# or yet better C++, then learning Objective-C wont be that hard.
iPhone/iPad is Apples new successful business, and they will do anything to keep this business growing, maybe they will not ban Monotouch apps now, but who knows there next move? So if you are really really interested in iPhone dev, instead of having nightmares that your work might be just rejected. Just switch to XCode, at least that will lower your app reject percentage. Hence, my advice.
I think something to strongly consider is Apple's motivation.
I agree with other sentiments posted online that Apple is trying to prevent commoditization of applications - that is to say, having more and more applications written using frameworks that generate applications that can run across multiple devices.
But that's not what Monotouch is. Monotouch is all about using the Apple frameworks to write applications - but through Mono, not Objective-C. So from that standpoint what Monotouch is doing is not something that should really bother Apple.
I still hold that developers are better off writing in the native language of the platform they are using, as things are just generally smoother when you don't introduce system that can have abstraction impedance mismatch - the Cocoa frameworks were all built to be used from Objective-C, and they make the most sense when you are used to the philosophy of Objective-C. But I do hope that Apple comes down on the side of allowing MonoTouch to be used.
All Apple is saying is that you must all now use 1980's languages to develop your competition beating state of the art Mobile Applications....
Makes perfect sense. Sounds like a winning strategy to me.
It also stops you from using any 3rd party libraries that you can't guarantee that have been developed in straight C, C++ or Objective C.
So basically it means that you can't buy in Games API's such as Unity.
Just adding my 2 cents. It seems that after reading this part: (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited) there is nothing to discuss. They have expressed them unambiguously. Not only they are banning MonoTouch and Unity3d, it seems they are also banning Titanium Framework. However, after reading this article, i found myself really confused.
I am not familiar with US laws, but is it legal? I mean, aren't they breaking some anti-monopoly laws?
Besides all of this, i can't understand their motivation. Not only will they partly lose a developers interest, they will also lose a developers respect, i think.
As of today, Section 3.3.1 of the Apple iOS Developer Program License has now been reverted to the old text:
3.3.1 Applications may only use Documented APIs in the manner
prescribed by Apple and must not use
or call any private APIs.
Apple has released an official statement on the license changes.
This would indicate that it is now permissible to use MonoTouch.
One goal of the Mono team is porting Silverlight to the iPhone by mean of MonoTouch/Moonlight for cross platform development. That's a bit like porting Flash to the iPhone. There is also Monodroid on the way to help us porting applications and, you know, Apple runs amonk every time someone says "Android" :-) IMHO, if Apple is targeting Adobe with the new agreement, they are targeting Novel too. We are probably speculating and there's a NDA but many of us invested a lot of time on this platform so we need to make the situation clear. We cannot wait next summer to discuss this matter. For example, I've been asked by a friend to help his company to prototype a MonoTouch application for a customer. Does the new agreement only affect the App Store distribution? What about in-house distribution?
This google docs spreadsheet has a long list of apps that will be affected by the new agreement. Some noteable ones that have been #1 in the appstore for their category:
Monopoly
Lemonade Tycoon
Skee ball
The settlers
Zombieville
One of the funny inclusions is Toy Story.
oMany apps have been accepted within the last few days written with the help of monotouch and unity, whereas I also am using it as well as obj-c, since the announcement and change in the agreement, so GO FIGURE,...the good ol'WTF comes to mind. It is a bipolar piggybank it seems.
ALSO, the last Unity Game GiantMOTO, which is under HOT NEW GAMES - YESTERDAY, has on its splash screen onLoad in big letters, POWERED BY UNITY. So, all the conjecture, assumptions, etc. is really out the door. It might say all that in the new version, it is certainly NOT enforced. And montouch is the only development platf that FULLY exposes iPhone API and builds COMPLETELY into obj-c using XCode.
From what the license agreement says MonoTouch apps will clearly not be allowed in the AppStore.
The more interesting question is though, against which framework / apps will they enforce it? They will also have to write automated tests to check if the apps were written natively or not, because the people who approve the apps won't have the time / skills to do it for every single app. These apps won't put a sticker there 'Using MonoTouch / Flash'.
Short answer to all that blob in the agreement is YES.
Apple is basically shooting itself in the foot by limiting programs to a few languages:
C - which is not really suited for application development these days, due to it's low-level nature. It's mostly a systems programming language today.
C++ - which makes it harder to shoot your phone, but when it happens, it's with a bazooka. Apart from Qt, there aren't any complete application frameworks to use in C++ (and Qt doesn't support iPhone - yet).
Objective-C - which was invented by Apple and of course will be supported.
JavaScript running in WebKit - basically a web application.
They are deliberately limiting what tools you can use to develop for iPhone, which will almost certainly get them in serious trouble. I'm sure a good sized chunk of the community will just quit iPhone development and migrate to a different platform like Windows Mobile, Symbian, Android or Maemo, which are totally open - you are free to write your application in LOLCODE.
Apart from possibly making iPhone junk for developers, it also gives Adobe a nice kiss:
Apple deliberately blocks Flash from iPad, and now they are also blocking it from iPhone. The nummer is Adobe Flash's CS5 biggest feature is deploying Flash applications to iPhone.
tl;dr: Apple is basically shooting itself in the foot with this move.
It's now months after the flash debacle and it's pretty obvious Monotouch and Unity are doing just fine.
As per "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited"
Monotouch compiles code down to a native binary, there is no "layer". They're referring to somethign like a .NET runtime, Java JVM or Flash runtime.
Mono applications would normally compile to bytecode which is and would require JIT (just in time) compilation to run them thus a .Net framework or Mono framework is required. However, in the case of iOS and Android, Mono application compile to native code. Therefore, in the eyes of Apple, there is no third layer, Apple will never ban Mono. So you can feel free to develop with MonoTouch and distribute your apps. To ensure you further, there are various of Mono applications (including games and applications) on the AppStore that have been around for a long time.
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.
As a .NET developer, I always dreamed for the possibility to develop with my existing skills (C#) applications for the iPhone.
Both programs require a Mac and the iPhone SDK installed.
Appcelerator Titanium was the first app I tried, and it is based on exposing some iPhone native api to javascript so that they can be called using that language.
Monotouch starts at $399 for being able to deploy on the iPhone and not on the iPhone simulator while Titanium is free.
Monotouch (Monodevelop) has an IDE that is currently missing in Titanium (but you can use any editor like Textmate, Aptana...)
I think both program generate at the end a native precompiled app (also if I am not sure about the size of the final app on the iPhone as I think the .NET framework calls are prelilnked at compilation time in Monotouch).
I am also not sure about the full coverage of all the iPhone API and features.
Titanium has also the advantage to enable Android app development but as a C# developer I still find Monotouch experience more like the Visual Studio one.
Which one would you choose and what are your experiences on Monotouch and Titanium?
Like any which-tool-or-platform-or-language-or-framework-or-whatever question, it should really come down to what you want.
Forget all the if-you-want-to-develop-for-this-platform-then-you-have-to-pay-your-dues advice. If you're interested in learning Objective-C, Xcode, and associated Apple bits, then go for it. I did. It's been fun, but my interest was in developing iPhone apps. Learning a new language, framework, and IDE was just a bonus (I like this stuff). It was also necessary when I started.
I've been working with MonoTouch since it was released, and I love it. I prefer C# to Objective-C, and I like having access to the subset of the .Net (Mono) framework that MonoTouch provides. There are certain things that are simply easier to do with .Net than Cocoa (string manipulation, date manipulation, anything XML, etc.).
I also like not having to deal with reference-counting anymore. I was spoiled by years of not having to keep track of resources at that level. I don't mind having to clean up after myself, but I don't want to have to manually do something that every other modern dev platform I've used does for me automatically. Plus, even for seasoned Objective-C devs, reference-counting isn't a no-brainer. Scroll through OS X's console output sometime to see how many apps crash due to memory-management issues (I know - this can happen with basically any app, but it's far easier to make the mistakes that lead to this situation when you get overworked devs involved whose attention spans have been destroyed by twelve hours of if this and if that and else this and else that and blah blah blah).
I still use Objective-C/Xcode - I've really learned to like Apple's tools. I honestly feel they're awkward and a bit arcane, but still fun.
But... then I also like this:
public string SomeString { get; set; }
To do the same thing with Objective-C (on the iPhone, anyway) requires that you declare a local variable to back the property, write the property declaration, and then use the "synthesize" directive to have the property generated for you (depending on what property attributes you specify, you might have a property that wraps getters and setters that take care of reference-counting for you - overall, this is a time-saver, but the C# Way is the clear winner here).
That's just one example of how MonoTouch can make your life easier, especially if you're used to .Net/Java/Python/other languages that don't require that you get your fingers dirty with memory-mangement (unless you want to).
As far as iPhone-ness is concerned, aside from brining part of .Net to the iPhone world, the MonoTouch namespace maps to CocoaTouch, so if you're confused about, say, the MonoTouch UIViewController, you can just hop over to Apple's docs on the UIViewController. MonoTouch .Net-izes CocoaTouch, but it's close enough that you're unlikely to hit a wall (that wouldn't have also hit if you were using Xcode/Objective-C). It's slick.
Titanium is different. Since they're trying (trying) to create an abstraction layer that lets you write the same app for multiple platforms, you're going to deal with the usual drawbacks: Totally different APIs, loss of flexibility (the same could be said of MonoTouch, but not remotely to the same degree), and basically having to learn a whole new platform (which is what you're trying to avoid by getting around Xcode/Objective-C/CocoaTouch, right?).
I also hate JavaScript, so I'm going to be biased against Titanium. But even if that weren't the case - even if I could use a language I do like - the APIs don't tickle my fancy. Or my anything.
Regardless of the dev tools you choose, you will end up having to learn something about CocoaTouch. Whether it's Xcode/Objective-C, MonoTouch, or Titanium, something is going to break or go all wonky on you, and you're eventually going to have to refer to CocoaTouch documentation.
If I were giving a talk on iPhone development (which I have, and which I will be doing again), and if I were to discuss alternatives to Apple's dev tools (which I will), I would still strongly encourage devs to at least work through a few basic iPhone apps using the native tools. It's going to make you a better developer for the platform - period. And you can use this beginning phase to determine if you even want to use anything other than the free Apple-supplied bits. You might not. I've been using MonoTouch because it pleases me - not because it's necessary.
So, to summarize a few basic criteria:
Preference (language/frameworks)
Devices (do you care about non-iPhone platforms or think you might someday?)
Comfort (if you like and know C# MUCH better than Objective-C, there's no reason not to go with MonoTouch)
And don't listen to the naysayers unless they've actually used the tech they're talking about. For example, I've read about Titanium, but I'm not experienced with it - I just know that I don't want anything to do with it on account of my preferences. That doesn't make it "bad" - just something I don't want in my life.
The Objective-C crowd can be impressively zealous. While there are plenty of open-minded devs in it, there are so, so, so many who think Objective-C and Cocoa and blah blah blah are THE last dev tools devkind will ever need.
Ignore them.
If you're worried about support, here's some stuff to consider:
Apple is likely to remain current, as they're the ones making this junk.
MonoTouch is likely to remain current - the Mono peeps have done an amazing job keep up with Microsoft, and I see no reason why they won't do the same with Apple. I'm blown away by what they do. And despite MonoTouch having been released, like, five minutes ago, they already have an update out for iPhone 3.1 stuff. They're serious about this, and I think they're magic. They're the Keebler Elves of the dev world. They sit in their secret layers and crank out stuff everybody (ok - not everybody) likes, but that nobody else would even attempt to do.
Titanium is either going to become an awkward unified API for writing apps for multiple platforms that is entirely its own thing, or it's going to become more and more splintered as the capabilities of different platforms diverge. Yeah, that's a bunch of typical armchair nerdly future-gazing... I should have prefaced this bullet item with "It's my opinion that..." If only there were a way to go back and change it.
Go with what you like. MonoTouch is a "safe" alternative to Apple's stuff. I'm afraid Titanium is going to go down the same old oops-this-super-high-level-platform-abstraction-layer-stuff-doesn't-really-work road that so many other technologies have. But if you're doing something simple, there's no harm in giving it a shot, especially considering that it's free during the beta period.
These are fun and interesting ways you can build iPhone apps. But, for truly rapid native iPhone development, your best bet is the free iPhone SDK and Xcode.
To be honest, the hardest things to learn are the capabilities of the frameworks themselves, NOT the language syntax. But that is an issue you have to tackle either way as these IDEs/Languages still require you to grasp some of the conventions of Cocoa (and Cocoa Touch).
I don't say this as a Cocoa / Objective-C snob, but if you know C (which as a C# dev you do) there really isn't any barrier to entry.
In addition, you will have access to tons of tutorials and sample code that just won't be available for these fledgling translators/IDEs/languages.
Learning another programming language is rarely a bad thing, and as an experienced programmer, your time investment won't be as large as you think.
I've created an open source project http://propertycross.com that helps developers select a cross-platform mobile framework by showing the same application implemented with Sencha, Titanium, Xamarin and more. This project allows you to easily compare a wide range of frameworks in terms of end-user experience, code, IDE, developer experience etc ...
I kinda like the idea of providing means to quickly get a grip on iPhone dev with techno people already know.
I personnaly, as a Java developer, use iSPectrum (http://www.flexycore.com). It also come with an IDE, debugger and stuff, which make it really convenient to develop with because it benefits of all the power of Eclipse Java plugin.
Being based on Java, this also allows to easily reuse already existing code from other java apps, which can be really handy providing that Java is present on almost all platforms (desktop & mobile alike) except iPhone.
Plus it's free for open source projects.
I'd rather consider these kind of solutions, because I don't like the idea of coming back to developing in emacs :) .
I know this is an old topic, but in the interest of staying current, it looks like MonoTouch and other cross-platform frameworks are going to be banned in SDK 4.0. Your only "safe" bet for writing iPhone apps is to use XCode and Objective-C, at least for the time being.
If you're C# programmer why you shouldn't invest some times to learn Objective C. Honestly speaking, it will not take much time from you. But you feels good to work in a new platform with new language. Learning new things all time fascinates me.
There are numerous ways to get on the device. Apple has stated in the SDK license that the only approved way to get on the device is via C, C++, ObjectiveC, and Javascript.
It appears at this point in time that apps built on MonoTouch and Appcelerator Titanium are being accepted into the App Store. Thanks to the license change, there is much fear, uncertainty and doubt on this subject. Apple has scared everyone not doing ObjectiveC.
I would suggest that you do whatever makes the most sense for you as a developer. If you know C# and .NET, you should go with MonoTouch. If you know ObjectiveC or the Mac platform, ObjectiveC is probably the way to go. If you know X and it's on the iPhone, well, X is where I would suggest looking first.
I have C/C++ experience so learning Objective-C is not completely foreign to me. However, I noticed that writing an application for the iPhone is not as simple as for the desktop platform. Should I start to get some solid experience on the desktop before I jump into the iPhone? I am not a commercial developer, and merely doing this as a hobby and for learning purposes. What is your recommendation?
For what it's worth, a comment from another newcomer to iPhone development...
My background - I was a C Programmer about 15 years ago and since then I've moved around technologies quite a bit - I'm now an Adobe Flex developer in my day job. By night, however, I'm trying to transform myself into an iPhone developer ;-)
So I bought a book on iPhone SDK development - 'iPhone in Action'. I also bought 'Programming in Objective-C 2.0'. I thought I'd be set with these two but after a couple of days reading and working through exercises it was clear that... I was hopelessly lost!
So I bought another book - this time, 'iPhone SDK Development' from the Pragmatic Bookstore - this is a work in progress book but looked 'right' for me. Turns out this book took me further - it's a great piece of work - however, the early chapters were paced nicely and I was able to follow along and then all of a sudden they began to assume I could recall perfectly the lessons learnt and the procedures followed in earlier chapters and I began yet again to flounder a little - the worst thing I find when trying to learn something from a book is to have to jump around from place to place constantly to make any sense of what I'm meant to be doing.
So (yeah, I know... but bear with me...) I bought ANOTHER book... 'Beginning iPhone Development' from APress. Now THIS book assumes nothing. For a beginner to iPhone development, THIS book hits the target. No jumping around necessary and finally I found I was progressing.
However, what I'm finding is that ALL three books in CONJUNCTION with one another really seem to provide me with a more complete picture - collectively I have a great set of tutorial and reference material. The Objective-C book I've not touched on so much yet but I expect that to be what I need it to be - a reference manual for the language; I'll not need that until I'm much deeper in to the guts. I'm slowly emerging from that horrible "in at the deep end and I can't swim very well" feeling to one where I can at least tread water. Hopefully with a bit more paddling I'll be able to touch the bottom - certainly my confidence is returning ;-)
So anyway, to address the original question - personally if I did this all over again, I don't think I would have gained anything by starting out building for the Mac first and then to the iPhone. I would definitely have lost less hair had I bought the APress book first - that for me was the book that made complete sense of everything for me. I think then the 'iPhone SDK Development' Pragmatic book was the best backup/followup book. This is the path I've suggested to a colleague and I'm confident it's a good one.
Hope this helps!
Jamie.
It is definitely helpful to have some Cocoa experience before going into iPhone development, but I personally wouldn't sweat it that much. Learning how to use the Cocoa framework and getting comfortable with it in general would be beneficial, but there are certain aspects of desktop Cocoa programming that you will find have little relevance to iPhone programming (e.g. user interface design with Interface Builder). Also, there are unique aspects of iPhone programming that normal Cocoa programming won't really prepare you for. (Some experienced Cocoa devs still had somewhat of a learning curve when they first got into iPhone development.)
In other words, I would recommend learning the fundamentals of normal Cocoa development, but you won't need to become a Cocoa guru in order to learn how to develop iPhone apps.
If your only intend in coding desktop apps is to get familiar with Objective-C, cocoa and Xcode, it is not worth.
You will learn nothing starting with desktop apps that you would not learn getting straight in iPhone apps. Desktop apps are not simpler than iPhone apps, they are just different.
It may even be counter productive if you learn specificities of desktop apps that you will have to 'unlearn' on iPhone development.
Of course, if your intend is to get into the OS X ecosystem, learning both would be very valuable.
In some ways the iPhone is simpler for a C/C++ developer. No garbage collection is the big one. If you start on the desktop and get used to GC, you'll have a hell of a time when you hit the iPhone.
There is no need to or benefit in learning desktop Cocoa before moving to UiKit on the iPhone. There may be some disadvantages.
Although there are a lot of concepts shared between UIkit and Cocoa they are no easier to learn on the desktop. And at the end of the day, they are not identical. Similarly there are a lot of frameworks that are shared between iPhone and the desktop - in these cases, there is nothing to be gained from using the desktop versions before their equivalents on the phone.
There some difficulties that you will face only on the iPhone and things that might make things easier on the desktop:
you develop on the target machine, on iPhone, target management is more difficult
iPhone is memory and processor contstrained
there is no Garbage collection on iPhone
My view is that it is a good idea to get used to these issues as soon as possible rather than getting into "bad habits" on the desktop (or just generating misunderstanding when you go to iPhone).
If you have any development experience you know that all languages are alike, and you only know if you fully grok it only by working with it.
My approach to learning a new development environment is to pick a problem you want to solve (and since the phone is in your pocket all the time, you're likely to have some idea), and bang your head on it.
There's a ton of apple sample code, answers here and on other sites. Start with a working sample app that is not too far from what you want to do, and tweak it over time. You are gratified by a working app, find out about problems right away, and can learn small bits at a time.
The biggest challenge is not learning Cocoa and/or Cocoa Touch but Objective-C. Once you have the fundamentals Cocoa is simple and similar to many other OO frameworks.
I suggest:
The Wikipedia article on Objective-C: https://en.wikipedia.org/wiki/Objective-C
"External links" at Wikipedia for some fundamentals of the language
Hot Cocoa podcast: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=294050835
Cocoa Cast podcast: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=298413458
Then the Stanford iPhone Application Programming course on iTunes U: https://podcasts.apple.com/us/podcast/iphone-application-programming-spring-2009/id384233222
Join the developer program at Apple: https://developer.apple.com