In the last few months we've noticed that Xcode seems to be rebuilding our project every time we 'Run', even if no files have changed. How do I determine what is causing this to happen so that I can prevent it?
We did start using Swift in the last few months as well...not sure if it's related.
Also, one reason that the problem is so noticeable is because of some extra build phases that we have which execute shell scripts that take time.
I am not sure if it's intention by Apple, or an Xcode bug. However, you can select ⌘⇧R (command+shift+R) to rerun without rebuilding.
Related
After updating to Xcode 14.0 (happens still for 14.0.1, and 14.1) I felt massive slowdown in incremental build times even if changing just a single property. For my project it's 3x, but read about 10x or more.
To fix that, you simply need to add user defined build setting SWIFT_USE_INTEGRATED_DRIVER and set it's value to NO you can do so by going to project navigator -> select your target -> Build Settings -> Now you need to click on the plus in the section below and tap "Add User-Defined Setting"
Xcode should scroll to the field and focus on it automatically, but if not scroll to the bottom or search for your field in the filter on the right and set your value to "NO"
This topic is covered more broadly on swift forum and this is from where I got this fix
I believe this is a temporary solution, due to some swift driver issues, if I found it to be no longer needed. I'll update the answer. From my own observations, I can't see any parallel compilations tasks being run with the driver on. Only one big emit module for main app target.
Xcode 14.1 has the same bug. Due to the previous answer I've updated from 14.0.1 to 14.1 today and the build times increase from build to build in exponential manner, below tested for the first 10 subsequent compilations without (!) any changes to the code base:
Update: The problem occurs only after the first debug run with or without change the code base.
Interestingly the time cannot understand by sum up the part times shown in the build statistic:
Deleting derived data folder doesn't resolve the problem.
The only working workaround is to close/open the whole project, making some changes, compile, close/open etc.
It's a mess.
The last Xcode update (1 November - Version 14.1.0) fixed the issue for me.
When i updated to 14.0.1 i felt massive increase in the build time, it was extremely slow. Now i can't say is it like before, but for sure it's better.
Here is the summary:
Xcode 14.0.0 - Builds fast
Xcode 14.0.1 - Builds very slow
Xcode 14.1.0 - Builds faster than 14.0.1
You can also try to download and install an older version from here, if the update doesn't work for you.
I am posting this after reading many similar posts on here regarding this issue and none of the solutions that worked for other people not working...
Xcode Version 8.3.3 (8E3004b)
Swift 3.1
Things I tried
Deleting Derived Data folder
Deleting Workspace File
Cleaning Build Folder
Cleaning Build
Reinstalled Xcode (after complete removal)
I also looked for Swift Issues:
Removed all concatenating strings
Cleaned up Swift arrays and dictionaries
Added Whole module optimizations
This all started happening after last Xcode update of 8.3.3. My project was compiling within seconds and now I have to wait at least 15 mins for it to index, then 5 minutes to compile after everything I change even something small in code.
When Building, it get stuck in "Compiling Swift source files". Is there way for me to look in to where it is actually getting stuck?
BIG UPDATE
I tried pretty much everything. Read every article, post, ect. NOTHING worked. My project was created right after 10.0.
Solution
Creating a new project and copying each file worked! It used to take 8-9 minuted to build. Now less than 2 seconds!
Apple knows about this problem, and says that Xcode 9 beta will perform much better. Note that if you don't want to update to Swift 4, you can continue compiling in Swift 3 mode using Xcode 9. The big limitation is that you won't be able to submit your project to the App Store until Xcode 9 goes final.
Also, Xcode 9 contains a new build system. You don't get it by default: you have to turn it on for this project. Choose File > Project Settings and switch the pop-up menu to New Build System (Preview). This is experimental, but it will be the default build system eventually, so it would be interesting to know whether this makes an appreciable difference.
If you don't want to update to Xcode 9 beta, you will just have to do a binary search: comment out all your code and start adding it back, piece by piece, until you find that piece that's causing the trouble.
The best way to work this out is to find what out what the build is doing while compiling your code. This is a really useful tool to use: https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode
When you run this tool it will show you what methods are taking the longest to compile, and then you fix those. Once you have done that, you can also try the answer I gave here to decrease the build times: Extremely long compilation times with Swift in Xcode
In my simple app I have a few files that are tested by unit testing and uitesting.
I am pretty sure that in UITests I tested EVERY line in WLLoginViewController. The test passed, but it is not considered as 100% in code coverage for that file. Sometimes when I restart Xcode, run app again, clean app, hard clean app. Do some accidental things, it works. But run tests once again, and again it is not considered. Why? Any ideas how to fix it? Is it a bug?
As you already mentioned, sometimes Xcode says that you are testing 100% of your code and sometimes it doesn't. So it's really inconsistent. That is an indicator for a bug.
Since you are still using an Xcode-beta, it's most likely a bug in Xcode. I wouldn't worry to much since it's still a beta-version and would check later, when the final version is released.
Ok, I've found temporary workaround.
Remove derived data for your project (window->projects)
Quit Xcode and Simulator.
Launch Xcode with your project, and run tests.
Run tests again.
Remember to wait until indexing is finished:
Weird, but try and see:)
So this same problem exists for a long time apparently. I checked all the xcode 4 code sense problems and used their solution and it works. Right up untill I build the file to run and then code sense stops working. I Really dont want to keep deleting the file in organizer and restarting xcode everytime. Is there a simpler method to fix this.
The first thing I always do when I lose Code Sense is to clean the project. If that doesn't work I use Watchdog to clean it. Watchdog deletes the derived data for the project like you can do in Organizer but it allows you to set up a handy keyboard shortcut which saves a ton of time now that Organizer doesn't have a keyboard shortcut.
I have a question regarding Xcode and bundle resource copy.
I'm currently working on a project with a large asset library. So, a clean install, or a change in a bundle resource warrants a copy of the "new" bundle resource(s).
However, the problem that I'm currently facing is that Xcode is copying a part of my entire asset library every single time that the application is built. This behavior is super weird, since on all the projects that I've worked, Xcode only copied resources if they had changed, or if it were a clean install, or if there was something new that had not been copied before.
In this case however, it copied all the resources on a clean install (expected). However, on every consecutive build, it is still copying some of the files over. Now this is super strange, since none of the files have changed, and it is not copying all the files, only a small portion of them. One more thing - if I run the same app, with the same configuration on the simulator, the copy DOES NOT happen (moar strangeness).
Is there some setting that I can change, or maybe a flag that I can include that might prevent this from happening?
Thanks in advance for the help!
Cheers!
It's been a month since this question's been asked, and I've managed to find a "sort of workaround" solution.
Now, the reason I'm putting this in as the accepted answer is primarily because no other answer/solution has been posted as of writing this. If anything better is posted (or if I have an update), I'll be sure to mark a better answer as the accepted one.
Either ways, this "workaround" will work if you have a super large set of assets that don't change over consecutive builds.
The project I'm working on has a lot of audio and video files that have already been prepared, and aren't going to change (other than the occasional re-recording or something along those lines).
So, as my question states, Xcode was copying a subset of the resources. Ideally, once a resource has been copied (and there are no changes to it), it is not re-copied (at least not supposed to be re-copied) over consecutive builds. In my case, it was getting copied during every consecutive run, causing my total build to start time to be around 15 ~ 20 mins. I'd also like to point out that regardless of whether we used "run script" in the build phases or whether we had the media in our Xcode project, we were facing the same issue.
Solution:
What I did was I cleaned my project, deleted the app, and did a fresh install. So, the first time, it copies ALL the files over with the app. Also, the assets directory is NOT in my Xcode project. We've added a "run-script" phase, wherein we run rsync to copy the media from the media folder, over to the app, during every build.
Now, once the App has finished doing a fresh build; it would have copied over all the required media files.
Then, REMOVE/DISABLE the script, perform a Clean in Xcode (command + shift + K) and run the project again. This time, since there is no script being run, and since Xcode has performed a clean, wherein now it thinks that all it needs to do is re-compile the binaries, it builds super fast. Since I've NOT deleted the App, the media folder is still in my app, and my build to start times are now around 30 seconds ~ 1 minute (this includes sandboxing and code-signing). Code-sign and "sandboxing" the application still takes time, but this is waaaay better than having to wait 15 ~ 20 minutes every time I hit run. :)
Hope this helps!
I've got very similar situation. Also, I have 6 000 resources in my app, and even listing some of them (not copying) was a bit slow. I've found another workaround (very similar to yours, but a bit easy to perform). It was inspired by your one, so thank you very much!
I copied the target of the project, set its bundle id as the original one (it was automatically set with ${PRODUCT_NAME} from build settings) and removed all the resources from Copy Bundle Resources section. First time (after removed from device app) I need to launch the original target with its resources, but then I can build the copied target while resources are still on device.
Some advantages:
it's very easy to switch between both targets
no need two write any scripts (that was purpose I did not use your solution)
Fun with numbers:
58 seconds from "Cmd+R" to loading screen appearing with bundle resource.
20 seconds for the same interval with empty "Copy Bundle Resources" section. Not so good as yours improvement, but still makes difference.
Hope this helps too :)