Thanks to remind me that, I almost forgot. 
By the way, I didn’t find this myself, I just trying to understand how all this work.
So I’ll use this compiler (it’s not the default one) with garbage collection required. I get one warning:
cc1obj: warning: -Wuninitialized is not supported without -O
which gets away if I change the optimization level (for debug). Is that ok?
No, you’re right, I’m not smart enough to see the differences (and probably I’ll never be), but if I don’t set all options accordingly, the project won’t build. and that makes a difference. 
The project that Bernard sent to me was using ARC, not GC, and the use of assign for the NSMutableDictionary was what was causing his app to crash. Since he mentioned that he was interested in iOS as well as OS X, I think that ARC is the way to go – it certainly seems like the way Apple is pointing us. It is my understanding that ARC takes care of pretty much all the memory management as long as you stick to cocoa ( but core foundation objects are a different matter). If this isn’t true, I hope someone will enlighten me.
As far as retain, assign or copy, it seems like (from what I’ve seen) that as a general rule of thumb, you want to use retain for objects other than strings, where you use copy, and assign for IBOutlets and primitive types. I know this isn’t always true, but for someone starting out in Objective-C, it’s a place to start. I don’t even know whether we should still be using retain and assign, it looks like Apple is moving to strong and weak.
Ric
It takes care of most of the mundane stuff, but you still effectively have responsibility with things like properties.
You’re right.
Properties in projects/files with arc should be defined the same way as other non GC projects. Performance-wise ARC doesn’t drop performance like GC but arc is more statically while GC is more dynamic. GC had a big advantage with objects that are created at run time like ASOC. The big difference is that ARC is a pre compiler while GC works at runtime. The only thing I don’t like about ARC is that it behaves like a zombie (read:stupid). I mean It adds release and retains for you, it could also look if the coder has added a retain or release already but it doesn’t. Another dislike is that I’m not allowed to create C structure anymore with pointers to Objective-C objects. For tool free bridge types (you named core foundation objects) needs a special casting. ARC indeed only applies for objects that have an retain counter (Objective-C objects). In other words for lightweight high level applications arc can be useful but a lot of developers needs to work with core foundation types (which are faster).
However I like the @autorelease{…} because it makes your code better readable, increase performance and best of all you don’t need to have ARC enabled to use this. But I name this because it is introduced with ARC.
Thank you for all these informations!
. So, I’d like to have confirmation that I have understood the basics:
For ASOC projects, GC ON. No worries about Properties.
For ObjC projects, it remains unclear (sorry). There are a number of build options, certain seem to work, others produce run-time error, others produce fatal errors. These options, sometimes mutually exclusive, are:
a) the choice of the compiler
b) the CG options [unsupported/supported/required]
c) code optimization level
d) ARC
These settings, according to what I have read from you, seem to determinate how to set property attributes.
Now please, as a beginner in ObjC, I don’t want to generate debates on what is the best solution for a specialist working with C or core foundation, I would just ask for the best settings for:
considering:
Every hints are very, very welcome!
Regards,
Again I’d like to recommend to learn the language.
At least read Apple’s The Objective-C Programming Language
Look also into the programming guides for the basic Foundation classes (string, number, the collections, date, url)
Personally I read also these books, they were and still are very helpful:
Cocoa Programming for Mac OS X by Aaron Hillegass
Programming in Objective-C by Stephen Kochan.
Thank you Stefan
The Objective-C Programming Language is already in my iPad’s iBooks, I read it every night. but what I like is to read, test, read again, test again. I just wanted to get Xcode configured to play with these new notions.
For the moment I have the same tiny “application” (half a dozen of properties, four or five handlers and a basic interface with a window, some controls and table views). my more complex line is
classNames = [NSMutableArray arrayWithArray: [[theDictionary allKeys]sortedArrayUsingSelector:@selector(compare:)]];
So really the basics. May I go with the defaults settings?
Could anyone recommend an Objective-C book that is easy to understand in the same way Shane Stanley did with his great book. That’s of course provided that the individual has programing ability.
I like ASOC as it allows me to write simple apps that I can use at work. but if I can learn OC that will be a plus provided I have the time to dedicate to it.
I just had a look on Kochan’s book and its approach is non-C programming 
. I will personally follow Stefan’s hint and load these books on my iPad.
Leave them as the defaults. And if you’re writing Objective-C from scratch (no ASObjC), I think ARC is the logical choice .
I liked Aaron Hillegass’s book, but it does assume some knowledge of C.
I’m with Shane about this. I have the second edition and third edition and both of them are good. It feels good to have a book from a trainer and developer who helped building the Cocoa API. So you want to develop for Lion only I suggest your buying the fourth edition. The fourth edition is for Lion with ARC support but also Xcode 4 screen shots (this last thing I can’t confirm but it’s told me).
Thank you very much for these hints, if people like you find these books good and useful, they certainly are! I have downloaded the first (now free) edition of Hillegass’s book, but I found and bought the third edition. It has a non-negligible advantage: it’s a french edition. So I won’t pretend “I don’t understand this or this because it’s in english”
Thank you for the warning, Shane! Well, my reluctance about C won’t probably last longer than the one I had for Pascal when I left FORTRAN. So many programmers cannot be wrong! It’s more a personal problem than a language problem. Ok, back to library.
Speaking as someone who has actually done that very switch you are thinking about – less than a year ago, I might bring some perspective and tips. I’ve been away from this forum for a while so I didn’t see your post until now. You are obviously already going, and you have already received lots of responses, so you might not need my response. But for new readers, I hope that it brings at least some new views.
I have a long experience in AppleScript, and I also had an AppleScript Studio app that needed to be completely renewed, so ASOC seemed a natural step, but only after Shane had his ebook for sale. (And somewhat ironically, that is how I first learned Objective-C.)
I have used a number of programming languages (mainly high-level dynamic stuff like Lisp, Prolog, Perl, Matlab, but also odd things like APL, and a bit cheating in Java), but managed to avoid C. After having coded ASOC for several months, Objective-C seemed more and more viable, since, after all, you have to read the Cocoa documentation anyway.
My first reasons for going ObjC was that I feared that a couple of new classes would need more speed than ASOC could deliver, so I wrote that one in ObjC, and was satisfied, so I started to convert other stuff to ObjC. As in your case, this app does not speak to other apps (apart from Finder, System Events etc) so it doesn’t really need AppleScript – I just started with AppleScript because it felt the fastest way to get something done.
Translating an ASOC method to ObjC is reasonably straightforward, but despite the similarity, translating a whole class may not be as easy and fast as one might expect. One big class (my biggest) took me a whole week to translate and to reasonably debug! (And more to polish.)
When I did the transition, I timed many constructs so as to get a feeling of the kind of differences in speed. What is very annoying in AppleScript is that its speed depends strongly on the size of your strings and lists, to the degree that at some point, the script will simply choke and return nothing! That is my historical experience. In ASOC, all those coercions might be fast for a 3-character string, but if it is 500 kB, it is extremely slow (or stalls), and for lists, the situation is even worse.
Like you, I dislike C, but as others have said, most ObjC people only use the “good” parts of C. If your read an old book on C, almost half of the book appears to deal with how to increment pointers and with furious transitions back and forth with * and &. But if you look at, for instance, stackoverflow, people don’t fiddle with such things very much any more, unless they really have to.
As for learning, good books have already been mentioned. Apple has a good document “The Objective-C Programming Language” available in the docs and as a pdf on the net. The big drawback with all of Apple’s documentation on ObjC is that they take for granted that you already know C, so you have to find some other source to learn C (but my view is that one should skip all things that look ugly, and only learn the basic things about C).
Knowing that ObjC is a strict superset to C is very important I think, because it helped me very much to understand why ObjC looks the way it does, and why you have to add lots of “@” allover.
Now that most of my stuff is ObjC, I can look back and conclude what I think is the practical consequences when comparing AppleScriptObjC and “pure” ObjC:
Perhaps in contrast to DJ’s experience, I find that it is much easier to read my ObjC code than my AppleScript code when I revisit it after a few months! That may be a bit surprising, but ObjC tells me much more explicitly what kind (class) the variables and parameters are, whereas with AppleScript that is pretty hopeless unless you name all your things with a suffix indicating its type/class. Also, the ultra-long names in ObjC encourages a style that makes things readable, even to the extent that one can skim through code to get the hang of what it does approximately.
Finally, the way you explicitly distinguish between properties and regular instance variables is actually a good help as soon as you begin to have many of them. And the color coding in Xcode makes it MUCH easier than in AppleScript to distinguish between local variables and instance variables, and to distinguish between your methods and those of the inherited Class.
Because of this clarity, my program comments in ObjC are not so much about what the line does, but rather WHY I need to do it! Or pointing out that the result might actually be nil. WHAT the line does is mostly apparent. This is the opposite of Perl, where you have to comment every line to say what it is supposed to do! (And it is still obscure.)
All languages can be misused. The important thing, however, is what style the language encourages. In that respect, I like ObjC.
ObjC code is easier than AppleScript to restructure into smaller units by using Categories, and the compiler helps enormously whenever I want to rename variables/properties by “refactor” them.
Concerning object oriented: Although AppleScript is OO, it does not really encourage an OO way of writing code. You mentioned that your AS code more resembles old-style procedural coding, and I have certainly had a fair amount of that myself. ObjC, on the other hand, definitely encourages a style that is much more in line with OO and message passing, and it encourages such thinking (which also makes the error messages easier to understand).
Although I have always loved AppleScript’s dynamic interpretive nature (just hit run and you see the results), I really dislike the fact that it is so sloppy! There is no definition, and no dictionary, that clearly and unambiguously nails down what is valid and what is not, and exactly what the requirements are on parameters etc. With every new OS version, thousands of AS (apps) stop working because Apple has changed how an empty list is treated, or an empty string, or some undocumented difference between string, text, unicode text, or. zillion of other things. You never know, the best you can do is just “cut and try” – if it runs, good, but it might be broken in the next OS. With ObjC/Cocoa, I have only come across one real bug I think, and the documentation is MUCH more strict than anything AppleScript. With AppleScript, I always stumble into various bugs, either AppleScript itelf, or Standard Additions, or some app’s dictionary (such as Finder). With ObjC, they do at least list what is deprecated, so the chance of getting things to survive the next OS seems higher.
Learning ObjC is a much steeper learning curve than ASOC (if you already know AppleScript) so the start can be troublesome. For small or simple apps, I don’t think the trouble of learning ObjC is worth the hassle if you already know AppleScript, but for larger apps, and for apps you intend to maintain for many years, ObjC wins, not only for speed, but I think it is much easier to maintain ObjC code than AppleScript (unless very small).
Xcode 3 could not even point out my missing semicolons, but Xcode 4 usually does, so the syntactic pedantry of ObjC (relative to AS) is not so much of an issue because the compiler helps you.
I now do use also some “pure” C code, but I do NOT increment pointers! And no preincrement of variables!
If I were to recommend a prospective ASOC-to-ObjC converter some small tips, it would be to get hold of some good book on the combination of C and ObjC. The other obstacle that was annoying was all those cases where I need to have a non-object (such as BOOL, NSInteger, SEL, .) in a dictionary or an array. There are methods to wrap them into objects (mostly NSNumber and NSValue), but Apple has not provided any chapter of “wrapping for dummies”, so you have to find out yourself the hard way or get some good teaching source.
All of this may appear to be pushing for ObjC rather than ASOC, so perhaps I should end by saying that ASOC is much quicker to get started with to get things done. And for those who need to talk to other apps, it is terrific! And if you do not foresee the app to grow into many thousands of lines of code, or no need for blistering speed with large amounts of data, there might be no need for pure ObjC – the ASOC bridge may be good enough for many cases.