Popularity is unrelated to quality of code.
While it is true that popularity = bigger target = more incentive to attack the platform's security, it is also often used as an excuse to try to hand-wave away bad, insecure code.
Another platform becoming more popular would indeed mean that it would have more people targeting it. But it does not, in any way, mean that the people would have the same level of success exploiting it as they do Windows.
We could probably safely expect that the platform would be successfully exploited more than it currently is. And people that think OS X is a security panacea are living in a fantasy world. But the argument that "[i]f everyone jumps to another OS so will the security problems" is a woeful oversimplification, and confuses two separate issues.
Also, as a side note, people seriously underestimate the level of incentive that currently exists for targeting non-Windows platforms. It is not the case that the incentive scales proportionally to audience size. Any sufficiently popular platform is a desirable target to attack. It's not like a platform has to have 90% of the market to be worth the effort. The relative ease of attack is a far more important factor than the potential audience size once we're talking millions of users.
As for the rest of your comment: both Windows and OS X are conventional monolithic operating systems written in C with core facilities designed and built in the '90s. Both are multiuser operating systems repurposed for single-user deployments. Both have strong kernel/userland barriers with well-defined interfaces. In fact, if you've done systems programming on both, they simply aren't all that different, even to a software developer.
But: for the past 10 years, Microsoft has been getting hammered by attackers, and has the benefit of a decade-long trial by fire. So when Microsoft randomizes library offsets, they don't (for instance) miss the entire runtime loading subsystem.
Also: most of Microsoft's most sensitive application code is written in C for WinAPI on x86, which is one of the best-understood application runtimes in the world. Much of OS X runs on cross-platform Objective C, which has received nowhere nearly as much research. Put simply: nobody knows how to write exploit countermeasures for OS X. I think mostly because nobody cares.
(Again: I say this as a Unix dev from '93 at a company standardized on Macs).
So, to a good approximation, you can say that the command line is based on BSD, and the rest came from NeXT and Apple, with a bit of GNU mixed in.
The BSD heritage is rather insignificant when it comes to security, since the largest attack surface comes from Apple applications like Safari, or the file manager, or other apps the end user uses directly on a regular basis.
My mistake.
UNIX 03 certification means MacOS X is a UNIX. It doesn't say anything about its status as a BSD though.
I had to dive into it headfirst for a Black Hat presentation in 2007, in which we loaded probes into a running xnu kernel to detect hypervisors. I was surprised by how easy it was to navigate based on my familiarity with FreeBSD's kernel. Obviously, there's quite a bit of non-BSD code in OS X, but for anyone who has worked with a BSD kernel before, the similarities are impossible to miss.
Hell, even if you can't read kernel code, the fact that OS X has sysctl, doesn't have proc, and debugs with ptrace() doesn't tell you anything?