Does your app have a GUI, and which one (native / Qt / Gtk+)?
If not, the issues to watch out for (compared to Linux) are mainly in the dynamic linkage area. OS X uses '-dylib' and '-bundle' and in fact has two kinds of dynamic libraries (runtime loadable and the normal ones). Linux has only one kind (-shared), and is looser on this anyways.
If your app has a GUI, you'll need to recode the whole thing in Cocoa, using Objective-C. Meaning you'll be into a new language as well. Some people (like MS) have used Carbon (C++ API), but it's being phased out. I wouldn't recommend that to new projects.
Your best luck is using Qt or Gtk+. A native Gtk+ port has been (re)announced just some days ago (see Imendio).
p.s.
OS X does of course run X11 binaries, too, but pushing that to any of your customers might be a hard road. They're used to Aqua interface, and productive with that. Consider X11 only a very short term solution.
p.p.s. The number of open source addon libs coming with OS X is limited, and their versions might lack behind. Whereas in Linux you can easily require users to have 'libxxx v.y.y' installed, in OS X there are multiple packaging approaches (fink, macports) and for a commercial tool the required libraries are expected to be contained in the application. OS X offers 'application bundles' and 'frameworks' for this (local copies, making the application self-sufficient). Linux does not have such a concept. This will have a great effect on your build system as well; maybe you'll want to try something like SCons for all platforms?