OS X 10.6 support survey

I agree although your 0.01% figure is way off. Official marketshare is still 1.5%. Also… those of us who have been doing plugins for a long time (I started when 10.3 came out…) have long-term customers with a higher chance of using old software.

Still I agree JUCE should drop 10.6.8. support, but ideally not in between master branch version releases.

I don’t build on Linux, but I think requireing libc++ might have some consequences for that as well?

1 Like

It’s not a libc++ requirement, a fairly recent libstdc++ will do the trick

Earliest we target is 10.7, drop it!

1 Like

Maybe worldwide installation base unrelated to the audio-market is 1.5%. We honestly don’t care at all about some outdated computers in China that have no interested in our products. Why would we?

We have almost 70,000 NEXUS2 installations out there, and about 7 or 8 tickets that ask for an installer that works with 10.6. Some customer specifically updated their OSX version to continue using NEXUS.

We’ve been doing plugins since January 2001. We had customers on OS 9. We know all about long-term customers. That doesn’t mean we shouldn’t update our systems, SDKs etc. regularly and encourage our customers to keep up to date, too.

OSX 10.6 was released in August of 2009. Updates are free nowadays. Except ancient hardware, there is not a single valid reason NOT to update.


From our web-site’s analytics, 0.5% of Macintosh using visitors are on 10.6, and 10.5 comes close to the mentioned 0.01% figure with 0.02%.
Of course those numbers don’t necessarily reflect users. I’d guess many might be browsing on their laptop’s and tablets and not necessarily on their work machine. So actual percentage of users on 10.6 is probably higher than that.

1 Like

Here at UVI, our minimum is 10.7

1 Like

Thank you for all the feedback.

Based on your responses I’m going to propose that we will make JUCE 5.3 (the next major release) the last version that’s compatible with 10.6.


What SDK will that use?

I would suggest that you use the most modern SDK possible, but target 10.7.

For example I’m using the 10.13 SDK, targeting 10.7, and using the “LLVM libc++” C++ library in the Projucer settings. This allows access to most (maybe all - I’ve not done a comprehensive search) C++11 features.


Looks like 10.5/10.6 support has been removed yesterday.

Based on what you wrote above I expected 5.4 would do that, but I guess it’s 5.3.1.

I think it would be great to mark this as “breaking change” as it requires some of us to update their build procedures/minimal system specifications.

This commit is in the develop version, so it’s not in 5.3.1, but most likely in 5.4

That’s the final nail in the coffin for this argument imho. Either stay on your ~9 years old crap and deal with it, or move with the times!

1 Like

I reverted that commit for JUCE 5.3.1 (as it was just removing Projucer options, rather than introducing compatibility breaking changes in the codebase), but I’ll shortly re-add it to the develop branch alongside an entry in the list of breaking changes.

Once this commit is in place I’m going to begin removing ScopedPointer, Atomic and CriticalSection usage from the JUCE codebase, replacing them with std::unique_ptr, std::atomic and std::mutex respectively. Ultimately we will deprecate the former so we encourage JUCE users to begin using the std:: equivalents as soon as possible.


That’s good to know, thanks @t0m!

Fantastic news!

Remember that juce::CriticalSection is recursive and std::mutex isn’t though :wink:

Interestingly I was just checking the docs for std::recursive_mutex and saw that:

The maximum number of times that a recursive_mutex may be locked is unspecified, but after that number is reached, calls to lock will throw std::system_error and calls to try_lock will return false

Anyone have any idea what this number is in practice across the different platforms? Is there any chance of it getting hit?

begin removing ScopedPointer, Atomic and CriticalSection usage from the JUCE codebase, replacing them with std::unique_ptr, std::atomic and std::mutex respectively

Please be extremely supercritical because of subtil behaviour changes!

I don’t want to spend days/weeks again, spotting subtil behaviour changes/bugs, i don’t want to be some kind of quality assurance or beta-tester, and my customers too!

I don’t say never change a running system, but i lost so many time in the past because of changes in repository , it really gets on my nerves.


It might be nice to have some public documentation regarding the replacement of these classes so there is a strict and clear set of rules to follow when replacing them, this should allow us all to recognise when there are errors in JUCE (hopefully it wouldn’t get that far), it would also allow others to have a clear set of guidelines to follow in their own code, and we can contribute to the documentation it any gotchas occur after the update.

I have to say that often I’ve found I prefer ScopedPointer to std::unique_ptr, it creates shorter more readable code IME.


Have you got some examples of this? I’ve seen quite a few cases that claim this in the past that actually aren’t any different with the right tweaks.

Personally, it’s a bit too easy to abuse ScopedPointer so I try and avoid it wherever possible now we have move semantics in C++.

TBH I was trying to remember so after having a quick play this is a quick example of what i think makes it less readable.

class MyObject {};
void someFunction (MyObject*) {}

int main (int argc, char* argv[])
    ScopedPointer<MyObject> scopedPtr;
    std::unique_ptr<MyObject> uniquePtr;
    scopedPtr = new MyObject();
    someFunction (scopedPtr);
    // could use std::make_unique<MyObject>(); but it's not actually avalaiable in C++11
    uniquePtr = std::unique_ptr<MyObject> (new MyObject());
    someFunction (uniquePtr.get());

    return 0;

As mentioned in the comment make_unique() would be better (and safer) but it’s not available in C++11 yet, could of course just make one, maybe there should be a handy juce::make_unique() ? that might help a little. But I also dislike having to call get() in order to access the pointer, I prefer ScopedPointer in that it was more like an actual pointer, to confuse matters more you can dereference a unique_ptr so it sort of acts like a pointer but not completely. I just find that behaviour a little counter-intuitive, and makes for less readable code IMO - maybe I’ll get used to it and come to prefer it, that’s what happened with the auto keyword for me. Also maybe I’m missing something?

1 Like

What makes you be stuck with C++11? That’s already legacy by now… :wink: