views:

600

answers:

5

How hard will it be to transfer from my existing expertise in C# to building apps for the iPad/iPhone in Objective C?

+6  A: 

It's a decent sized jump, but you can learn enough to get up to speed in a few days.

Once you get the Objective C syntax and conventions down, you'll have to delve into the Cocoa libraries and frameworks, which are pretty substantial.

I would recommend getting a book on Objective C or iPhone development, or going through all the tutorials on the http://developer.apple.com site.

Once you get going, check out this site for good code examples for applications: http://appsamuck.com

Andy White
+2  A: 

I think if you know OOP you will be fine. The synthax is not usual as most programming languages though, e.g.

object.function(var arg1)

looks like

[object function[var:arg1]]

if I remember correctly.

If you have an Apple Dev ID and iTunes, you could go to http://developer.apple.com/iphone/index.action then go to the Getting Started videos (after which it should ask your Apple Dev ID at some point then launch iTunes). There you have a bunch of videos. The one called "Introduction to Objective-C and Cocoa Touch" can be a good start to look at.

Hope that helps.

SK.
I believe you mean `object.function(arg1)` and `[object function:arg1'` instead. The parameter types are specified when declaring a method/function, but not when calling it.
Quinn Taylor
Aside from the syntactical error in your answer (not a big deal), the way that Objective-C handles OOP may be different from what C# programmers are used to. Objective-C does not call methods, it sends messages (like Smalltalk and Ruby). That's an important distinction, and allows for a lot of really powerful dynamic coding.
Jonathan Sterling
Allright, thanks for the additional info!
SK.
+50  A: 

The language jump is OK. Once you get past the initial shock of [ and ]. However, the libraries and Framework shock will be substantial.

The Cocoa and Touch frameworks are significantly lighter when compared with .Net Framework, so at least you can look at the bright side, you have less to learn. But their underlying philosophy, layout and historic evolution path is very different from the C#/.Net framework. Whether this will be easy or hard, is difficult to appreciate. Some personal opinions:

  • The Cocoa way of building UI is light years ahead of anything .Net framework has today, Forms or WPF. It will be difficult to grasp at first, but if your grok it, it will make a LOT of sense. It is good ole' Model-View-Controller based on Smalltalk framework and will naturally guide you down a right path of designing UI.
  • Graphics, video, media are going to feel as from another planet when coming from .Net background. But despite their apparent arcane appearance, the Cocoa offerings are very powerful, although somehow low level.
  • Animation is going to be a huge sigh of relief. Cocoa animation is just plain easy to use, and there isn't anything equivalent in .Net
  • If you do openGL instead of Cocoa native graphics, then is openGL and openGL is pretty much the same flavor on any platform.
  • Network programming is poorer on Cocoa side. You have some basic support and gotta admit that at least the API is designed that is really hard to do stupid stuff (it forces you to use async programming, so no more one-thread-per-client non-sense), but I'd bet you'll miss the .Net sugar utilities (WebRequest, WebClient etc)
  • XML parsing. Cocoa support is just plain primitive. At least, again, the XML parsing is event driven so is going to guide you toward better programs, but is complicated to put together.
  • Database. Is going to be a different world. You have the choice of going raw SQLite or Core Data. Core Data is better imho. Is a high level ORM and active record kind of stuff, with all the intricacies of the underlying storage abstracted away. Easy to use and powerful, as long as you ask it to do something it knows how to do. Unbelievably cumbersome to force it to do something it doesn't know how to do. True for any ORM, ultimately. You'll miss LINQ, and you'll have to forget SQL. The gist of it is that the DB programming experience from .Net just doesn't transfer to Core Data world. The alternative of raw SQLite will look more familiar, but is very low level, will feel more like programing 1990 ODBC than 2010 .Net.
  • Key-Value Coding Programming. This concept has no direct .Net equivalent. It may sound like some sort of simple dictionary, but in fact is way more powerful. It interweaves with the runtime engine of the Objective part of [Objective-C] and gives birth to some neat tricks. You'll need to understand Key-Value coding to make efficient use of Core Animation or Core Data. You can think at it as reflection on steroids. It can achieve some of the same tricks Linq-to-Objects can do, but is not going to be anywhere as elegant as Linq.
  • Is C++. Objective-C is a superset of C++ and is backed by recent drops of gcc, so you can fall back to C++ anytime. STL, functors, template metaprogramming, they all work. You can mix and match in the same application pure Cocoa and Core Objective-C with C++. You won't be able to do something like inherit an Objective-C class as a C++ class, but you will be able to communicate between a C++ class and an Objective-C object. Not sure what is the current status of boost or Loki support.

Many of the areas covered poorly in Cocoa have various 3rd party libraries, but I can't enter into comparison all Cocoa 3rd parties vs. .Net 3r parties, I have a life...

Overall, I would sum it up shortly as In Objective-C the entry bar is higher. Bring a brain.

Remus Rusanu
+1, Wish I could give you more. Very informative! Even I got curious about starting to do development for the iphone. :)
wasatz
+1. I also agree with @wasatz.
sugar
You should be hired by the apple SDKs marketing team, you got me curious!
Stephane
I can 100% agree with this answer, it does exactly reflect what I have experienced when switching from C# to Objective-C. Some additional notes: Learning about Memory management (and the conventions around) is an absolute must. .Net Remoting sucks compared to NSProxy, categoties are far ahead of anything .Net can offer in terms of extension points. +1 for mentioning c++, it will make your life easier in some situations but you need to be careful about some gotchas.
Johannes Rudolph
+20  A: 

In addition to Remus's terrific answer, you will also need to understand and be able to implement memory management. If you grew up on Java or .NET, this may be alien to you. Pay very close attention to this part of the tutorials, and practice this by intentionally screwing it up. You need to know what these errors look like and how they behave.

Good luck!

Audie
+1 Oh my, I should had started with this. Very very very true.
Remus Rusanu
+1000! I spent a lot of time resisting learning reference counting, but now it's second nature. I prefer to work in garbage-collected environments (like Mac OS 10.5+), but it is important to acknowledge that `retain`/`release` is pretty painless compared to manual memory allocation in plain C.
Jonathan Sterling
At least Obj-C has relatively well-defined in object 'ownership' and standard counting support ... random C/C++ anyone? ^^
pst
+1 for the "intentionally screwing it up" part. Those kinds of bugs can be mindboggling at first contact. How I wish I had done that on purpose just to learn instead of spending whole afternoons chasing dementia-inducing bugs.
Martinho Fernandes
+1  A: 

The language isn't difficult but I found the development environment isn't quite as slick as VS in a few ways. For instance the interface builder is a distinct application to the coding environment leading to occasional synchronisation issues, and the compiler won't tell you if you typed an event name incorrectly.

Having said that the interface builder is gorgeous. You just need to remember to hit the save button before you flip back to the code.

Phil