1) Mac users are highly sensitive to the quality of your products' user experience. What this means is, go native or don't bother. Even though Google Earth and Photoshop are rife with UI atrocities, don't imagine that you can get away with ignoring the rules like they can. They're 500-pound Gorillas, and you're not. If you are Google or Adobe, get with the program and write a Cocoa UI, already. It's about time.
2) The native language for the Mac and the iPhone is Objective-C. Get used to it; it's not hard to learn. Any developer familiar with C should be able to learn Objective-C in a day, and be an Objective-C language lawyer within a week if he cares to. Yes, there are Ruby, Python, and other bridges you can use, and they work just fine, but limit this to integrating existing libraries with your apps. DO NOT try to use the bridges as a way to avoid learning the environment you're working with.
3) A cross-platform GUI is neither feasible nor desirable. You can't #ifdef the difference between Cocoa, xlib, and Win32. Don't believe me? Look at OpenOffice. (If OpenOffice looks OK to you, then please, forget about offering your products on the Mac. You'll only cause us pain.)
4) Don't bother with third-party cross-platform GUI libraries like Qt. Yeah, you can make it sort of work, but you'll get a lot of complaints from your Mac customers, and it will be more expensive than properly factoring your code and writing a native GUI for each platform. For every Mac customer who complains about a bad UI, there are many more who took one look at it and decided never to do business with the vendor in question. I just learned from a friend that Qt is far worse than I'd realized: if you use Qt, you wont' get any hardware acceleration , and you won't be able to deliver ADA compliance.
5) If you're shopping for people with years of experience in Cocoa and Objective-C, you should know that they're pretty scarce due to the flood of iPhone projects going on these days. I'm hearing about people getting $200 to 250/hr for iPhone projects. Keep in mind that you're also competing with Apple for those developers, and chances are your project isn't as interesting as Apple's. If you're a start-up and you can offer equity, then it's not too hard to find people who are willing to gamble with you if they believe in your business plan. Mac and iPhone developer tend to be somewhat less risk-averse than the average engineer, in my experience.
6) If you can't afford experienced Mac developers, you'll have to make your own. Save yourself a lot of time and money by sending your people to a class. I recommend Big Nerd Ranch, that's where Apple sent their own people when they quit doing Cocoa training in-house. Keep in mind though, that once your newly-minted Cocoa developers have a year or so of experience under their belts, you'd better be prepared to offer them market rates, or you'll lose them. Back in the NeXTSTEP days, Fannie Mae insisted on low salaries, and they lost people steadily to other NeXTSTEP shops. Attrition is expensive; it will cost you more than you think when your institutional knowledge of your product scatters to the winds.
7) Send your people to the Apple developer conference every year. I can't emphasize this enough. Time is money, and the connections you can make there with the Apple engineers you need to know can save you weeks or months of trial and error.
That should do for starters.
8) When interviewing an Objective-C expert, DO NOT try the "Microsoft style interview". (See #5 above.) We are not entry-level, fresh-out-of-DeVry kids who have the time for solving the little brain teasers that someone looked up on the web last night. Talk about the actual work at hand, how the candidate's previous experience is relevant to what you need to do, and ask for some examples of creative solutions they've come up with before.
9) Probably the best place to advertise for iPhone or Mac developers is the cocoa-dev mailing list at lists.apple.com. You have to be a subscriber to the list, and you have to send your ad to the moderator for approval first. In any ad on Cocoa-dev, be very specific about what kind of developer you're looking for, and what the job entails. This is not the place to just list buzzwords or try to lowball anyone.
10) When advertising for candidates, don't hide behind a webform or an e-mail address. Put a phone number in your ad that reaches a human being. People with skills that are in high demand aren't going to mail their resume to recruiter@companyNobodyEverHeardOf, because that kind of thing gets you spammed.