TLDR;
Assets(storyboards, images) not updating unless clean build with Swift package manager local dependency.
Explanation:
I use Swift package manager and have a local dependency (module) that has storyboards, image assets etc. However, if I make any change on them and just cmd+r to run the app, changes are not shown; for example, if I change label text on the storyboard, it won't show the updated text if I just run cmd+r.
To make them appear, I have to clean the build folder and re-run the app again.
But if I change any swift file it works fine.
Try just going to file>Packages>Update Packages To Latest Version
I had a similar behavior with one of my projects. Changes to the storyboard wouldn't be reflected in the simulator if I chose the new build system.
I know that the legacy build system is now deprecated, but you can still try to build with it and see if it is a bug of the new build system.
File > Project settings (or Workspace settings) > Build System > Legacy Build System
Try Updating the packages and also delete your derived Data and archives and give it a go. Seems more of a Xcode bug /cashe issue . Are you using Xcode 13?
It's difficult to find the exact reason because it could depend on several factors. When you open your storyboard file, go to Editor->Automatically Refresh Designable Views and be sure it's checked.
Check also Xcode->Preferences->General->Issues and be sure the check below called "Show Live Issues" is flagged as this picture:
Another reason about your assets refresh failure could depend by the missing resources inside the list: Targets->Build Phases->Copy Bundle Resources
Check also if your resources are shared with a file hosting service like Dropbox, it could be have a local cache which keeps the old version.
With any change in code (though file is not in .pch), complete project recompiles every time.
Update 2017/1/2
This issue has not been resolved at Xcode 8.2.1 (for my project)
How to survive?
Code IDE: Xcode/Atom
Build: xcrun
Debug: Xcode (Control + Command + R)
Update 2016/12/17
This issue has not been resolved at Xcode 8.2.
Update 2016/12/12
Atom to code and command line to build and debug is my choice now.
Hope Apple will fix this legit bug soon.
Update 2016/12/04
This issue seem resolved with Xcode 8.2 (beta 2).
But for me its not be resolved, i face this issue even when i use Xcode 8.2.
You can give it a try (download Xcode8.2 beta2 here)
Build System • Xcode will not rebuild an entire target when only small
changes have occurred. (28892475)
Old answer:
This is a work around:
"Build Setting" tab -> "C Language Dialect" -> Change it to "Compiler Default".
For reference:
The "C Language Dialect" was set to "GNU99" instead of "Compiler
Default". Previously the standard was GNU99 but now its not. At some
point Xcode did not migrate the library project settings correctly and
so it was set to GNU99. Once I changed it to GNU99 it stopped
recompiling all my code every time !
Go to Product -> Scheme -> Edit Scheme.
Select Build in left side column and uncheck "Find implicit dependencies"
But this flag should remain checked when you are building the project for first time..
Fix for me was just closing storyboard, I had the source file opened with the assisted editor and the storyboard file opened as well (closing the storyboard --- since I wasn't making any changes to it) removed all the unnecessary compiling
UPDATED
The single biggest improvement I was able to make was modularizing my project. Specifically modularizing the ORM layer which is used in almost every other class. By moving that code into a separate target within my project and importing it as a module I was able to greatly improve compilation times. No longer does Xcode decide to recompile unnecessary files when I do a build.
Now I use the Single File compilation method for fast incremental debug builds.
There are some other good suggestions in this link including code refactoring,
https://medium.com/rocket-fuel/optimizing-build-times-in-swift-4-dc493b1cc5f5
OLD
Still has been a constant issue for me with Xcode 9. Like many of you I'm working on a large swift 4/cocoapods project with many source files and re-compiling every file every time is infuriating.
So far I'm getting the best results with the following settings. I suggest you give it a try and see how it works for you.
Schema -> Build -> "Find Implicit Dependencies" = TRUE
Build Settings -> Link-Time Optimization = Incremental
Build Settings -> Optimization Level (Debug) = None [-OO]
Build Settings -> Optimization Level (Release) = Fastest, Smallest [-Os]
Build Settings -> Increase Sharing of Precompiled Headers = YES
Build Settings -> Enable Incremental Distill = YES
Added custom User-Defined build settings,
Build Settings -> HEADERMAP_USERS_VFS = YES
Note: I do not have the custom user-defined setting for whole module optimization.
I changed a few things with my code regarding the prefix header that seem to have fixed this problem. I don't know which one actually did the trick, but I'll share them all in hopes that it helps someone else out there. If you don't have a prefix header set, then I guess this isn't the problem (or the problem is multifaceted).
Remove any imports from the prefix header that are files from the built products directory so you can change the build setting for this ("Precompiled Header Uses Files From Build Directory") to "No". Be sure it is not indirectly imported through other imports as well.
Remove any imports from the prefix header that use Clang modules (libraries or frameworks that have a module.modulemap file in their Headers directory, so you can write code like #import MyModule). (For me, this and step 1 were one and the same.)
Set the build setting for prefix header sharing to "Yes". (I don't think this is necessary, and it shouldn't have any effect in my own project. I'm just stating this because I changed it because I was willing to try anything. :))
Exit Xcode and delete your DerivedData/ModuleCache directory (configured to be at ~/Library/Developer if I remember correctly).
If that still doesn't work, you can try removing some more imports from your prefix header. There may be something tripping it up...
Looks like they are actively working on it according to https://forums.developer.apple.com/thread/62737 but a workaround is to add
HEADERMAP_USES_VFS = YES
under the build settings of your target (Project -> Target -> Build Settings -> User Defined).
This solution worked every time for me today, after no other solution working consistently for the past month.
EDIT: Still sometimes recompiling everything, although it seems to do it much less frequently with this setting defined.
Check out all of your code on #IBDesignable directives in my particular case Xcode build project all of the time because I had some views on my storyboard that was contain this #IBDesignable attributes in it.
Second thing is that I also have my storyboard opened in separate window (not tab) that is push my Xcode make builds for all of simulators forever.
Madhuri Mane is totally right regarding this. To add a little more clarity, some important points to note:
This is ONLY applicable if you have implicit dependancies on libraries/frameworks that your target relies on.
If "Find Implicit Dependencies" is disabled :
Result: The library will not get built prior to building the
application target. The application target fail to build.
Fix: To ensure that the second scenario does not happen, you must add
the necessary targets into the targets list and order them correctly.
Source and further reading on the topic : https://pewpewthespells.com/blog/managing_xcode.html#scheme-action
Now if your entire project is housed within one target and that takes 4 min to compile there isn't much you can do about this except break it up into frameworks to take advantage of the above or figure out where the compilation lags. If you are using something like PaintCode or have large chunks of UIKit code in swift change it to Objective-c it compiles far faster
Go to your target's build settings and set Defines Module to Yes.
Worked for me for a couple builds, too soon to claim this is a definitive workaround, but at least we're trying.
Apple released new beta version of Xcode yesterday (Nov 14)
Xcode 8.2 beta 2
And this issue has been marked as resolved in the release note.
Build System
• Xcode will not rebuild an entire target when only small
changes have occurred. (28892475)
It is working for me. The build speed came back as usual.
Everybody who is facing this issue, should give it a try!
https://developer.apple.com/download/
Please go to the build setting of the project and change the "C Language Dialect".
The "C Language Dialect" is set to "GNU99" instead of "Compiler Default" when you update the xcode version. At some point Xcode did not migrate the library project settings correctly and so it was set to GNU99.
This will solve the problem
If you have made changes to the Swift file start building the app, go to the last tab and click on the build log, during the "Check dependencies" stage stop the build and run it again. On the second run it should only build the files you modified. If done correctly I have found it works every time. No need to make any project setting changes.
This appears to be a bug in Xcode.
If you see the app is doing a full build then stop the build and try this trick again.
If you have made no changes to the code use CMD + CTRL + R to run without building the app which attaches debugger. Will not build app but can help save unnecessary time.
Issue from my side fixed by applying the uncheck to "Find Implicit Dependencies" solution.
BUT remember if you're using cocoapods, to apply this settings also to your pod project by selecting it from
Product -> Scheme -> Pods-"yourProjectName"
also apply in:
Product -> Scheme -> "yourProjectName"
It help me, so i hope this hint helps someone else.
Thanks
Try to:
1. Navigate to Project
2. Click Build Settings
3. Check that OptimizationLevel is set to None for debugging.
4. Click Add User-Defined Setting
5. Set SWIFT_WHOLE_MODULE_OPTIMIZATION to YES.
to fater compilation time of xcode ,can make use of IRAMDISK(Virtual memory disk) . Very useful and effective means to reduce compilation time.
Also can use to speedup frequently used application.
refer following link to download and use:
http://iramdisk.findmysoft.com/mac/
I have a library project that used to build just fine in Xcode 7.2. If I just compiled it, it would rebuild it on subsequent builds. After upgrading to Xcode 7.3, Xcode recompiles all the files on every build even if I make no changes to any file.
I did a deep clean and also deleted the derived data folder to make sure that was not the cause. The dependent library projects build fine (they don't recompile everything) when I compile them independently. I have looked through all the settings but couldn't figure out why this is happening.
I stumbled upon 2 things that "fixed" the problem but I don't want to use any of these "solutions"
I changed the Optimization Level (for LLVM) from None [-O0] to Fastest, Smallest [-Os] and that did the trick. Im not sure why without the optimization it recompiled all the files, all the time (even if it was not changed).
I have a pre-processor flag (DEBUG=1) for debug builds and if I remove that flag then it stops recompiling all the files, all the time
The above 2 options don't work for me.
Has anyone seen similar behavior?
I figured out the problem. In Xcode one of the Build Settings was not set correctly.
The "C Language Dialect" was set to "GNU99" instead of "Compiler Default". Previously the standard was GNU99 but now its not. At some point Xcode did not migrate the library project settings correctly and so it was set to GNU99. Once I changed it to GNU99 it stopped recompiling all my code every time !
I have returned to a fairly large project that uses RestKit and many other libraries.
The existing target builds and archives fine. Xcode 6.4, SDK iOS 8.4, target iOS 7.0.
I did this:
Duplicated the existing target.
Added some pre-processor macros and a different product name
Expected the new target to build and archive successfully.
Now the build fails with:
(null): Library not found for -lPods-AFNetworking
NOTES:
I have compared the raw target details and they are identical apart from the few changes I noted above.
I don't really want to run pod install on the project. Why? Because I'm afraid, yes. And because I don't want to spend much time - I just need to make a variant build and then move on to something else. A pod install after a period away could cause unwanted breakage.
I have had this problem before on the very same project, and yes I am cursing the former me for not making better notes at the time, but the former me says that he was fatigued and pissed off with it at the time and couldn't bear another minute, and knew it would come back to bite the later me in the arse.
So now before I bang my head against this again, I am hoping a kind and generous soul reading this will share a golden path of light that leads up and away from the pain directly to the promised land of a clean build.
I have recently upgraded to cordova 2.1.0 and previously each Xcode project referenced its own cordovalib folder.
I thought I understood that if you want an Xcode to use a cordovalib on its own and not share it with any other projects, then you can run
./update_cordova_subproject
in
Cordova-2.1.0/lib/ios/bin
and that if you don't run the update script with its parameters then you can share the CordovaLib.xcodeproj file across many projects. However if I open two Xcode projects that reference the same Xcode project I get this error:
Cordova-2.1.0-global/lib/ios/CordovaLib/CordovaLib.xcodeproj Couldn't load CordovaLib.xcodeproj because it is already opened from another project or workspace
and if I try opening the CordovaLib/CordovaLib.xcodeproj file I get this error:
The file couldn’t be opened.
However all projects run without any problems.
Quitting xcode and reopening the project without any others that reference the same cordovalib open removes the error.
Does this mean that:
I cannot share a CordovaLib.xcodeproj file across many projects and each project has to have its own cordovalib that it references, otherwise I could run into serious problems in the long run? Or
I can share a cordovalib across many projects but can only have one Xcode project open at any point in time and that I will not run into any serious problems in the near future?
Is there something I am overlooking?
I have tried googling the problem but most of the questions refer to previous versions of cordova whereby the method of referencing the CordovaLib was different.
Thanks in advance.
You can reuse the subproject, but you can only have it open in one app at a time.
Not a problem if you only work on one thing at a time like most people, but since my current preferred development setup involves 18 desktops and never closing anything, I work around it with git submodules - each app gets its own fully independent copy of Cordova without actually keeping a separate copy in source control.