OS X has come a long way since OS X 10.6.8; among the pluses: better multiple monitor handling, considerably improved memory management (part of which was fixing the leaks in the color management pipeline that OS X 10.6.8 exhibits) repairs to the bugs in 10.6.8′s CUPS printing system, and so on.
So why, then, target OS X 10.6.8?
The first and perhaps most important reason is because 10.6.8 was the last version of OS X that provides PowerPC support through emulation. There are literally tens of thousands of applications that were written for the PowerPC version of OS X, many of which were lost to anyone who moved beyond 10.6.8, as the developers were no longer keeping those applications up to date. This kept many people using at least one machine with 10.6.8, including myself. If my development targets anything from 10.7 onward, I am effectively preventing my application from running on those machines.
Aside from intentionally keeping 10.6.8 around for its own merits, there are whole classes of Apple computers that have to stay with OS X 10.6.8. This is because 10.7 and onwards completely dropped support for 32 bit processors. So for instance, that very, very expensive 17-inch Macbook Pro people bought in 2006? The highest OS X it can run is 10.6.8 as it uses Intel’s “Core-2 Duo” CPU. The same goes for many of the Macbooks and the minis, and for the same reasons — they simply cannot upgrade the OS. So if I move to 10.7 development or later, I have to build 64-bit executables, and then my applications won’t run on these machines.
Next, developing for 10.6.8, at least as of OS X 10.11, has not impeded my applications from running on later versions of OS X. There have been a few things I have had to instruct my users how to do, such as turning off Apple’s "App Nap" and unloading certain Apple USB drivers that, if left loaded, break otherwise correctly functioning software. But these have not been show-stoppers, as they can, in fact, be gotten around.
This means everyone running the major releases of OS X can use my applications: Snow Leopard, Lion, Mountain Lion, Mavericks, Yosemite, and El Capitan. In addition, I can properly support the many 32-bit machines that remain in use. So my userbase is very broad indeed under this approach.
At this point, I should mention that I have moved to Qt for my software development. This gives me a software development platform with considerably better control over UI graphics and frees me from Objective C and its successors. The main problem I have with Objective C is not the language, by the way, it’s Apple’s minimalist UI builder. Almost everything I want to do is very convoluted and troublesome doing it Apple’s way, particularly when it comes to dynamic control creation. Within the context of Qt, it all becomes very easy, because I have complete control of the classes that generate the UI controls (widgets) I am interested in manipulating.
There’s an additional benefit that is very significant: Under Qt, I can build for Windows with the same source code I build for OS X. This enables another huge group of users — in fact, a group larger than the OS X group.
However, choosing Qt has pinned me to a particular release of Qt, because Qt has very poor version-to-version compatibility. If I move to the next release of Qt, it will require a very large effort to change my source code, and once that’s done, I can’t go back — and just as you might have already guessed, the next version of Qt won’t run under OS X 10.6.8 either.
The upshot is that I have to work around or otherwise put up with whatever bugs exist in Qt and OS X at the levels that I am developing under, and of course, there’s no taking advantage of later features in either; if it’s not in 10.6.8 or Qt 4.7, I can’t use it. And if a feature I’d like to use, or am forced to use, is broken in either of those products, then it’s broken, period.
So far, holding to these development stages has only given me one really serious headache, caused by 48 KHz maximum sample rates via the audio input support classes provided by Qt 4.7. Those limits have caused one of my applications to provide a less flexible set of audio input options under Windows, which in turn limits the Windows version of the application’s usability to users of a particular low-end SDR, of whom there are quite a few. There may even be a way to work around this by building a completely custom sound system for the Windows version, though I have to say such an undertaking does not appeal to me even a little bit. Just as an aside, I formally reported the problem to the Qt developers, even going so far as to identify exactly where in the Qt library source code they had imposed the limit for them, but they never "got around" to increasing or eliminating the limit.
So that’s the story, or at least, most of it. The bottom line is that my choices here don’t mean that my users can’t upgrade their operating system and/or computer. It just means that I have not (yet) been forced to, and because of that, I can support a much broader range of users under both Windows and OS X.