Sequoia/Xcode 16 compatibility

What is the current situation with Sequoia/Xcode 16 and JUCE 8?

Is everything working correctly? Do I need to be on the very latest tip of develop or is the master branch building correctly, etc?

You’l need to be on develop. However, I think the only commits required are…

1 Like

Thank you, @anthony-nicholls!
What about Xcode 16 with Sonoma, does that still require those commits?

Yeah same commits, it’s an Xcode requirement due to changes in the shipped SDK IIRC. I don’t think anything is needed for Sequoia specifically other than you must use Xcode 16.

Juce 7 build out of the box with Xcode 16 on Sonoma. Probably because it still uses SDK 15 so I guess it’s the same for Juce 8

Are these fixes the ones needed for juceaide on Juce 7?

Yes.

You will need a JUCE 8 licence to use the IP in those commits in any projects, even if those projects are based on JUCE 7.

1 Like

Man, that kinda sucks.

All that hassle sorting out the license stuff when Juce 8 came out and now we’re stuck on an old O/S for Juce 7.

So in order to keep working on client stuff that requires Juce 7 because they don’t need to pay for a license we’ll need to keep VMs around of Sonoma to do our builds on. Yay. Should’ve stuck with Projucer!

Is anybody seeing these dual errors when launching JUCE apps from Xcode:

You can run Xcode 15.x on Sequoia via the command line. Only opening from Finder won’t work.

so is it possible to install XCode 15, change cmake to use xcode 15 and then build juceaide?

@AScheffler that’s a good tip! I did also wonder if you could point Xcode 16 to the macOS 14 SDK shipped with Xcode 15. I recall this being a semi-regular pattern that I had to follow many moons ago.

IMO Apple were a bit heavy handed removing createImageFromCGImage from the macOS 15 SDK given it was only deprecated in macOS 14, the replacement was only available since macOS 14 (we actually ended up using a function from 14.4 in our implementation), and then they only shipped the macOS 15 SDK with Xcode 16 while simultaneously requiring Xcode 16+ on Sequoia! It seems more aggressive than usual, especially for something seemingly innocent that could probably be implemented internally using the new SDK functions.

@leehu it’s worth adding it’s not just juceaide that’s impacted, anything depending on the juce_gui_basics module will hit the main issue relating to createImageFromCGImage. It just happens that if you’re using CMake juceaide will be the first thing to build that depends on that module.

1 Like

yeah, that does seem like a hell of a lot of stuff to wrap up in one fell swoop…

Not tested with Xcode 16, but in the past I was able to have a previous version of Xcode on the drive just for the SDK, and direct the compiler to use that:

macro(setRequiredXcodeAndSDK MAC_SDK_VERSION XCODE_DIR)

    set(MAC_SDK_DIR "${XCODE_DIR}/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs")
    set(MAC_CURRENT_SDK "${MAC_SDK_DIR}/MacOSX${MAC_SDK_VERSION}.sdk")

    if (IS_DIRECTORY ${MAC_CURRENT_SDK})
        message("Using Mac OSX SDK ${MAC_SDK_VERSION}")
        set(CMAKE_OSX_SYSROOT ${MAC_CURRENT_SDK})
    else ()
        message("Can't find Mac SDK ${MAC_SDK_VERSION}, switching to default instead")
    endif ()
endmacro()

In the past that worked for me with pointing to some other beta of xcode that I installed from Apple Developer.

1 Like

thx for the tip. will give this a go over the weekend.

Just an anecdote, but I’ve had no issues so far with sequoia across 5 different plugins I’ve tested.

I previously had some issue with Xcode 16 on Sonoma, but Xcode 16 on Sequoia is working great.

I’m using the latest develop branch of JUCE and all works great. I just had to regenerate the Xcode projects from projucer.

Just a naive question, but do we know when these fixes will be merged into the master branch and a new Juce version will be officially released?

1 Like

That isn’t a naive question at all.

We balance a number of factors when deciding to do a release, and some of those include the stability of the more recent commits on the develop branch and the need to get fixes like this out to people who need them. Ultimately it’s not predicated on any single thing, so from the outside it’s difficult to predict with much accuracy.

In any case we’re aiming to get a release out today.

Thank you for your reply and your explanations @t0m , I really appreciate and it makes total sense.

In previous versions of Xcode, the -ld_classic flag had to be added (many threads on that on the forum).

Xcode 16 says this flag is deprecated. Can it be safely removed now?

2 Likes