Usually, if you specify an explicit macOS deployment target in your test project using e.g. -DCMAKE_OSX_DEPLOYMENT_TARGET="10.14" (or whatever minimal deployment target you are aiming for) you’ll get a compile time warning if you are using an API that is not supported for that macOS version. You can then use e.g.
if (__builtin_available (macOS 11, *))
// code path for macOS 11 and higher
// fallback implementation
I hope I didn’t tell you stuff that you already knew anyway
It might be worth inspecting the deployment target of the resulting binary using otool -l. I experienced two cases where the expected deployment did not match the actual one, first was not declaring the CMAKE_OSX_DEPLOYMENT_TARGET as a cache variable prior to the project call, the second one was when a subproject included from the top level CMakeLists also declared a deployment target and silently overwrote the top level target.
Thanks for the support everyone. Just a heads up that I’m working on compatibility for older macOS versions now.
@Fandusss I don’t want to turn this thread into a general JUCE discussion, but I have to say that working on this gave me a new level of respect for how just much work goes into building and maintaining a foundational cross-platform framework like JUCE. Not only did I spent weeks auditing, testing and benchmarking available algorithms on multiple platforms, but I had to brush up on image compositing, package for release (still need to get tests in CI) and now there are all sorts of cross-platform and legacy version challenges.
So this one tiny piece of the pie basically took me 2 full time months of dev time. I honestly feel quite grateful that all the really hard stuff in JUCE (compositing, painting, platform and DAW compatibility, parameters, audio APIs) is just handled — we never really see the details of that work or know how much time goes into getting it solid.
Perhaps it’s also ideal for little specialized pockets of things like blurs/shadows and other UI niceties to be open-source third-party modules. The JUCE team is quite small and they have a very large list of actually hard fundamentals that are constantly breaking! For example, I can’t imagine the time investment with something like unicode support (announced with JUCE 7). Based on my recent experience, I’m guessing a solid dev-year or more of work? (Looking forward to my emojis! )
@sudara (and all those that have been contributing to the blur investigations and improvements) this looks really interesting .
@sudara I just went to try and run this and hit issues with it trying to use vImageSepConvolve_ARGB8888 (and some other similar methods) these appear to be macOS 14.0+ and I’m running 13.5.2. Am I missing something?
Oh also, the blog post about the module made the front page of hacker news yesterday, in case anyone wants to check the comments out there — some interesting implementation ideas (and amazingly nobody was rude/mean this time!)
I don’t think we do a very good job of communicating how difficult the problems JUCE faces are, especially for tasks that appear relatively small. From the outside I suspect it often looks like we’re presented with fully-formed ideas or code and then it takes us months to actually implement any changes where we have spent weeks JUCE-ifying things unnecessarily. Having another voice saying it can be much more difficult than you expect is welcome.
I’m sure there are lots of exceptions to the above, please don’t derail this thread with your favourite grievance! I just wanted to thank Sudara for his support.