My code has all the retain/release calls in it of course . . . is it likely to be easier to write the mac app with garbage collection (and then what do I do about the retains/releases) or without?
Whichever way you recommend, any pointers about relevant Xcode settings would be helpful. Thanks.
I highly recommend that you not use GC on Mac for various reasons, just stick to what you're used to doing already. I believe that when you rely on GC to manage memory, you give up a lot of fine-grain control, which I personally don't enjoy doing.
Since you're already coming from a reference-counted environment like iOS, I think that it would be wise of you to stay in that environment, given that it's not going to take much more effort on your part at this point.
You will need to port your view controllers and view-based code to Cocoa, but that shouldn't be too much of a hassle. You can drop in your models, because they don't have any view dependencies. (of course assuming you did it with an ounce of sanity).
I'm going to respectfully disagree with everyone who has answered so far and tell you not to immediately dismiss garbage collection on the Mac. All of my Mac applications use garbage collection, and all new applications I build will do so.
Where garbage collection has saved me a tremendous amount of trouble is in heavily multithreaded code. I consider myself fairly sound when it comes to memory management, but edge cases involving release and autorelease across threads were leading to occasional crashes in a massive piece of robotics control software until I converted it to garbage collection. All of those problems went away afterward, leading to far greater stability overall (I went for six months without seeing a crash on one of the more recent versions).
If developing code that will be shared between Mac and iOS, definitely write following the standard memory management rules so that you keep up your good habits and guarantee that things can be copied and pasted back and forth. You can then enable garbage collection as a build-time setting in the Mac version to act as a safety net for those cases where you missed a leak or overrelease. You won't be saving on code this way, but this might improve the stability of your application when deployed to your users.
However, there are certain frameworks, like Core Image, that don't play well with garbage collection, so if you use one of those in your application you may need to avoid GC.
As Mike Ash points out in his article "Perform Better With Garbage Collection", the fact that the garbage collector operates on a background thread can lead to slight performance improvements with certain applications on multicore Macs. For example, it can prevent halts in the main thread that you sometimes see in tight loops as autorelease pools are being drained, or other objects are deallocated.
Finally, I like testing crossplatform Cocoa code of mine under garbage collection to identify where I've put non-memory-related cleanup code in -dealloc (where it really doesn't belong), because -dealloc is no longer called under garbage collection. This helps me to better architect my code.
Keep it the way it is. Not using GC will allow it to run much faster on the mac. It also gives you much more control of when things stay and when they go, and will probably give you a more stable application in the end.
It will also make it easier for you port things you write on the mac back. Doing it will also keep you in the habit if you go back to iOS.
So in short if you already do memory management keep doing it!
