Xcode 8 recompiles every file every build

Whenever I make a change to a file, like add a new property or create a new class, Xcode recompiles every single file on a build, and it takes quite some time. I've got this happening on the GM on two different computers (one running 10.12 one running 10.11).


I've tried:

  • copying every file to a new Xcode project created in Xcode 8 GM
  • removing every "Other swift flag" flag
  • removing all third party libraries
  • comparing my project's build settings to a new project's build settings
  • remove all test targets leaving just the one target I need
  • removing all ObjC code
  • removing all ObjC related flags


Really the kicker is that moving all my code to a new project shows that it's something in my code.

Any ideas? My productivity is way down having to wait ~ 1.5 minutes for every build / auto complete / syntax highlighting to work. And yes, I've cleared derived data 🙂



UPDATE:

One more peice of information, I found this information https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160411/001693.html


which tells us about a "-driver-show-incremental" flag, which will cause queued dependancies to be listed in the build log. Sure enough I see what I think is every single swift file I have listed in the output. Trying to figure out if there's a way to make sense of what the dependancies are...


Output is something like:


...

Queuing Form.swift because of dependencies discovered later

Queuing SignInViewController.swift because of dependencies discovered later

Queuing EditProfileViewController.swift because of dependencies discovered later

Queuing ChangePasswordViewController.swift because of dependencies discovered later

Queuing JoinViewController.swift because of dependencies discovered later

...

Hmm, if I generate an ipa archive and rename it to .zip, then you can decompress and get to the bundle. Inside the bundle there is a _CodeSignature folder with a CodeResources file. Its just xml but there is a key for "files". My guess is that would have atleast 450 entries for your pictures. Each item looks like there is a base64 string associated with it. ( I can tell because there is a "=" on the end ... plus its xml ) So maybe there is some over head per file such that it takes 8 minutes generating somekind of signature.


Or perhaps some of those images are big -- like raw? Might just be one of them -- maybe an artist messed up. For kicks, as a test, if you did not include some of them in the project would it speed things up? Or any image file in particular? Having a large number if images should not be out of the ordinary for an app.


It might be interesting if you zipped all those images into one file, then when your app first runs decompress it out into multiple files. Or if they could be downloaded off a server when the app first runs then there would be no code signing for these images -- that might be a more scalable approach and then users could download the app on cell connections.


Random ideas...hope that helps.

I will make some tests with your suggestions, but the "Signing product" time seems not correlated to the number of images.

Just to mention, for a pair of times the compilation time was just 40 seconds or so, without any reason, but in the last 5 compilations, again, 8 minutes and more, just for signing the product.

PS: tried to compile with 10 pictures instead of 450; no differences at all...

Horrible !

When I build my code sign is doing something like:


CodeSign /Users/USER/Library/Developer/Xcode/DerivedData/XXXXXX-XXXXXX/Build/Products/Release-iphoneos/XXXXXX.app

cd /Users/USER/Desktop/ZZZZZZ/XXXXXX/XXXXXX

export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate

export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"


Signing Identity: "iPhone Developer: XXXXXX (XXXXXX)"

Provisioning Profile: "iOS Team Provisioning Profile: com.XXXXXX.XXXXXX"

(XXXXXX)


/usr/bin/codesign --force --sign ZZZZZZ --entitlements /Users/USER/Library/Developer/Xcode/DerivedData/XXXXX-XXXXX/Build/Intermediates/XXXXX.build/Release-iphoneos/XXXXX.build/XXXXX.app.xcent --timestamp=none /Users/USER/Library/Developer/Xcode/DerivedData/XXXXX-XXXXX/Build/Products/Release-iphoneos/XXXXX.app


So, seems like there are limited options here. But what would bug me is I see timestamp, Intermediates and DerivedData. Maybe something is not being cleaned up from the last sign -- something left in derived data from the last build. In Xcode 8, there was a suspicious change with removing the ability to delete derived data etc. The only influence I can see in this step is cleaning out derived data and or not including files in a project to avoid the sign. But as a user, I should not have to worry about it ... it should just work. I guess it does but takes 8 minutes in your case.

One last follow up question, if you are using Mac OS Extended for your partition, is it case sensitive or not case sensitive? Perhaps that might cause some people to have issues and others not. My partition is not case sensitive ( probably is not a good idea for development )

I think the only way to solve this is to start contacting the technology press and point out how a trillion dollar company cannot fix for more than three months a bug that kills developer productivity entirely. This is completely ridiculous.

I've seen on some other threads people might have too many development certificates loaded into their key chain that is causing signing to be slow. Anyhow, once the unecessary certs were removed it appeared to speed signing up for other people. Perhaps, that might be the same issue? Might be another point of failure.


I've had the proper number of certificates in my keychain and signing seems to not be an issue for me.


Perhaps the bug is how all these certs got into the keychain in the first place.(?)

Also happened to me. I'm very frustrated!
Xcode 8.2.1 keep compiles every single swift file in my project even I only add one letter to one file.

This happens to my code as well. Every time I make a code change, it takes hours to recompile another file which I did not change at all.

That other file had a large code footprint which is unavoidable.


Is there a way to directly use the compiled object file(the .o file) at link time and tell Xcode not to recompile that specific file?

We had this issue as well and I found a workaround that is working for us.
In our project we are using CocoaPods and I noticed that when you change something in the code XCode doesn't recompile the Pods frameworks. Inspired by that I created a new target (SDK) that builds a framework containing code we are not going to change very often like: networking stuff and model structs. I added this framework as a target dependency on the main target. The framework creation is an annoying task because you have to add a lot of `public` keyword in order to see the SDK classes from the main target but build time has improved a lot now. I suggest to try this approach for the moment.

here is my two cents.


Background: I replace existing code signature of Xcode(8.2.1) using my certificate in order to use plugins I rely on . (mostly for XVim)


This problem started happening after I have revoked the existing certificate. I replaced signature of Xcode with new certificate but it had the same problem.

Then, I downloaded Xcode again from the developer downloads page and replaced signature with new certificate.

This made the problem go away.


Hope this can help.

I'm using Xcode 8.2.1 and a small change in one file still causes the whole project to recompile, not always, but most of the time. I work on a large project with hundreds of source files, a recompilation takes about three minutes. I guess that I spend about a quarter of my time waiting for Xcode to compile when I try out something new that requires frequent recompilation. So unfortunately the problem still isn't fixed and it brings Xcode to the brink of being unusable. This is really absurd.

I experienced the same issue, however mine was down to @IBDesignables constantly rendering out causing the build loop. Try updating to 8.2.1 as this fixed the problem for me.

Also running 8.2.1 and xcode recompiles everything each time(objective-c and c++ project). I will have to admit that I haven't read every post in this thread but the summary of possible solutions from this thread and stack overflow seem to be...


make sure optomizations are turned off

use only dwarf debug info

turn off 'find implicit dependencies'

set HEADERMAP_USES_VFS to YES


In my case another interesting side effect seems to be a complete rebuild when I hit run, even if I have just hit build and then made no changes. An interesting way to test if this is happening for smaller projects is to use this neat recursive template to increase build times for one file in your project that you never change... https://randomascii.wordpress.com/2014/03/10/making-compiles-slow/

I've used the xcode default project for making an opengl game with only gamekit and it seems that in that scenario xcode does not do any rebuilding... ie include the recursive template if the template is changed build times are 30 seconds, if changes are made in other files build times are instant. Really not sure what changes I have in my project that make it build all every time versus the sample project but perhaps its time to create a new project file.

Hi,


This happened to me, no matter which Xcode and what settings. It just keeps constantly rebuilding the whole project.

Fortunatelly I find a solution and I think it will solve this problem for many of us.


here is the link to the stackoverflow thread about it. Enjoy

http://stackoverflow.com/questions/28476030/xcode-keeps-building-storyboard-after-each-keystroke

So i found a solution for this problem.

It is simple as:

1) Open your target build settings and set the optimization level to None in your debug configuration.

2) Add a new user-defined setting called SWIFT_WHOLE_MODULE_OPTIMIZATION and set it to YES


This will enable super fast compile times while allowing you to debug the application.

using the XCode UI to set the optimization level will add the flag -O which won't let you debug the app.

So what we need is just the swift whole module optimization alone.

I tried it and seems to help. Anyway, with this flag on I can't compile my test bundles anymore.


I get a bunch of:

Undefined symbols for architecture x86_64:
"direct field offset for ............
........
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see `invocation)

Any working update? I tried everything in this thread and no one is still working. Thanks you.

Try to find @IBDesignable and comment it. It solved my problem

I've been having issues as well. It seems connected to the use of CoreData. I have read through the comments and tried many of the suggestions...no improvement! Sooooo frustrating. I'll be reporting a bug...

Xcode 8.3.3 this issue still happen.

I just edit some code lines in a class file the xcode re-compile all source files ?


@Apple how do I help you reproduce/solve this problem plz, It's take us a lot of development time.

A completely justified rant, by someone with the scars.


Yet another year goes by, and the Xcode toolchain remains fundamentally broken.

Version 9.0 (9A235)Xcode 9: can’t type a character in a Swift source file without the entire project rebuilding. Or sourcekitservice crashing. Or sourcekitservice gobbling up all available system RAM.


I’ve done everything people recommended here and on StackOverflow over the years. Every build setting, every clearing of the cache, every script, even rebuilding projects from scratch. It’s all been for nothing.


It’s impossible to work like this. Whole days of my working month are spent waiting for Xcode to rebuild, after typing a single character in a Swift source file. The productivity is pitiful. No wonder people opt to use tech like React and Javascript for their "native" apps. Apple, you're not giving them much choice.


Year after year, Xcode gets new features added to it, and surprises are sprung on us at WWDC, but Xcode remains a basket case; a perennial Beta not suitable for production work.


What is the good of filing radars when they are ignored, and Xcode is released once a year for marketing purposes, obviously broken?

This is so incredibly poor. Xcode is not a professional development environment, and by extension, nor is iOS/macOS development. I’m sure individual engineers at Apple are committed to Xcode, but there is obviously a problem with tool leadership at the company.


Instead of adding new features to Playgrounds, how about FIXING Xcode’s most basic behaviours?


And how about a development roadmap, instead of springing major, broken releases on us once a year?


Maybe it’s time to open source the toolchain, ala Swift? It’s not like Xcode has any great business advantage for Apple right now.

Maybe Xcode should be forced through the same App Store review process we go through?


Grrr.

I was able to resolve this issue by adjusting settings in the build phases for my target.


We were using a custom script build phase step to insert preprocessing flags into one our cocoapod depedencies. Changing that .xcconfig file caused our project to re-compile on every build or run.

Checking the box ' Run script only when installing' underneath the script editor in the build phase step solved the issue immediately for us.


PROJECT SETTINGS > BUILD PHASES > (custom script) > click 'Run script only when installing'


Now I have my productivity back!!



Note: You may not have a custom script but I would inspect all of phases in case one is touching the config files for either your project or your dependencies.

I filed a radar for the original issue with the -driver-show-incremental setting crashing Xcode. I'm pretty confident at this point that the dependency graph is the source of our troubles with very long build times in Xcode (still in the latest 9.0 and 9.1), but without this flag working I'm not sure what options we have to troubleshoot.


rdar://35128994

Just adding to the pile, I miss objective-c.

I've tried all the suggestions uptill now, My compilation time is 2 minutes, when my project was pure objective-c, compile time was less than 20 seconds.

Xcode 8 recompiles every file every build
 
 
Q