User modules not rebuilding on change in Xcode 10

I haven’t looked deeply into this yet, but it seems like since upgrading to Xcode 10, my user (JUCE) modules are not getting recompiled when changes are made.

The steps to reproduce in my project would be:

  • Make a change in a module used by my project (e.g. DBG() statement)
  • Build and Run


  • The project is re-compiled taking into account the changed files


  • The previous build runs

In order force a rebuild I have to do a complete clean first, which is time consuming.

I can’t reproduce this for modules within JUCE itself, only with my own module. I didn’t experience this with Xcode 9.

Can anyone else reproduce this?


1 Like

I can confirm your findings using Xcode 10 beta 6.

Whoa. Not good.

I’m having the same issue here (Xcode 10.0 release version). I can’t even see the content of my custom module folder within Xcode. The folder appears but is empty (the files exists and are compiled, though, but again, they do not get recompiled if they change).

I can confirm the problem also exists in Xcode 10.1.

I’ve a hunch it has something to do with the unity build idiom used for JUCE modules, but I haven’t had time to investigate further.

Same here. Still on 9. Hoping there’s a solution to this somewhere in the works.

I’m using AppCode instead of Xcode, however, I downloaded Xcode 10 two days ago and suddenly I get similar problems in AppCode. Am I right to expect that in the end AppCode is just a different Editor but using the Xcode build system under the hood, so the update might have affected my AppCode behaviour as well?

1 Like

Edit: not fixed yet by Apple, I guess I’ll have to come back to Xcode 9. It’s a pity, haven’t had any problems with it for a month till now.

You need to enable the “legacy build system” for things to work.

Set “File/Project Settings…/Build System:” to “Legacy Build System”.

This setting will occasionally get erased when making changes in the Projucer.

Btw: When using the legacy build system Xcode displays a brown icon in its top status bar:



I can confirm switching to the Legacy Build System resolves this issue. Thanks @yairadix!

1 Like

And btw on latest JUCE head it now applies this setting for us!


This is good news.

Is there anything else that’s a show stopper with Xcode 10?

No 32 bit
I can get a reliable crash partway through typing an include path
Breakpoints are not always reliably set/hit


Isn’t this fixed with the legacy build system?

@t0m I can report that the issue reported at the top of is thread seems no longer a problem at least as of Xcode 10.2.1. It might be worth re-assessing whether JUCE should use Legacy Build or the New Build System. I am now testing with the latter and will report back here any issues or lack of issues.


OK. I can confirm that whilst the original issue is no longer a problem, switching to the New Build System breaks issue navigation. That is if I click an issue in the Issue Navigator, which relates to a file not explicitly added to a build target, Xcode can’t navigate to the file. If I can get around to creating an MCVE for this I might file a ticket with Apple.

Does the new build system actually provide any benefits?

The are various claimed benefits one of which is faster build times. My anecdotal experience so far has been that re-builds (i.e. after a code change has been made) are slightly faster with the new system. I would guess at a 10–15% speedup. If this claim is true, it would make more difference for bigger projects when making changes that may require lots of files to be rebuilt. Whereas I’ve observed no difference in building a project from scratch after a clean.

I also think Apple will now devote their energies to improving the new build system, and I’m guessing the legacy one will be dropped at some point.