I have an Xcode project (objective c, Xcode 8.2.1).
Whenever I do "Clean build" and build again, it takes a very long time. I started to look into the reason for this and I noticed that all my pod source files are being compiled twice (which I guess doubles the compile time).
At the top of Xcode, you can see the status of the build as it progresses
You can see in the screenshot above that Xcode is compiling 142 source files for the Realm pod, but it only has 71 source files. All my other pods have the same issue.
I tested creating a new xcode project and adding pods, and then I don't experience the same problem as in this project.
#Bdash suggested that I might be having the build setting "Build Active Architecture Only" set to "No", but I have checked this and it is set to "Yes".
Any ideas on what could be the problem here?
This tends to happen when you have custom names for your build configurations. That is, if you have a name other than Debug or Release, CocoaPods will treat such configurations as release ones. Besides other things, this means enabling optimizations and setting the Build Active Architecture Only flag for those Pods to YES. Both options will hinder compilation times for Debug configurations.
To fix it you have to specify which configurations are Debug ones. Following the docs, you have to change your Podfile so it looks something like this:
project 'MyApp', 'MyAppRelease' => :release, 'MyAppDebug' => :debug
Unfortunately, Realm is a large project with a significant number of C++ and Objective-C++ source files, and generally takes a while to compile (especially after cleaning the build folder). Exactly how long Realm takes to build depends on what sort of computer Xcode is running on, but the numbers you provided don't seem to be unreasonable for older hardware.
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 was running my app this morning and now all of a sudden I am getting the following error when I try to run on the iPhone 5.1 simulator.
Cannot run on the selected destination
The destination does not support the architecture for which the selected software is built. Switch to a destination that supports that architecture in order to run the selected software.
I deleted the schemes but still no solution.
I am using Mountain Lion. I am using xCode 4.4 (Recently upgraded to Mountain Lion and xCode 4.4)
UPDATE 1: Here is the view of my build settings:
UPDATE: Here is the actual error which prevents from it running.
You might follow the steps:
Quit Xcode and iPhone simulator
Unplug your devices
Goto /Users/your_usr_name/Library/Developer/Xcode/DerivedData/
Delete all data under this folder
Start Xcode again and run your project
Hope this will solve your problem.
I had this issue after updating from Facebook SDK 3.1 to Facebook SDK 3.1.1. My fault, I guess.
Inside "resources" folder, now there is a totally useless but dangerous info.plist that, if imported, may break your project file. Don't know why they included it but I believe few of us made the same mistake recently.
I found this problem with the version of Xcode 4.4. And finally I solved it this way:
Find the "Info.plist" in your project, then unselect the target membership plus on the right side view of window, it works for me.
You might also want to check if the project uses a supported compiler in the project settings
Its just duplicated Info.plist file
just use 1 Info.plist file in files then restart xcode
its fixed for me
I have just encountered this error in Xcode 4.5.1, and the error went away after I take all non-alpha characters out of the Product Name build setting.
I believe this may be a current unlisted bug with Xcode 4.4+. I have/had the very same issue with my project. I deleted all versions of Xcode and restarted with 4.4, opened my project and had the error again.
I then started a new project with a template with a different name. Did not have the issue.
I then renamed my old project, started a new empty project with the same name and built/ran and got the error again. This new project was nothing more than a view controller that didn't do anything. I should have gotten a blank screen but got the same error you did.
Frustrated I shut down for the day and re-ran the old project and it worked. I had not changed anything. Currently I have the error again and neither rebooting or restarting Xcode fixes it.
So in summary, a project can have absolutely no changes made, sometimes it builds and runs fine, sometimes you get this error. For the record I did not get this error running Xcode 4.3.
My issue did not show up until I upgraded to Mountain Lion and Xcode 4.4 which happened to be on the same day. Now I can not get back to a 100 percent workable configuration.
Committing my files to SVN and checking out the project in a new directory fixed this for me.
Look at both the project and target build settings, at that Architectures, and see if anything has changed. When first going from Xcode 3 to 4, it use to wreck havoc in a hidden way, giving the same error, and in the end you had to add i386 to the "Valid Architectures" line. I just looked at my big project started in Xcode 4.1, and it shows nothing about i386 etc, but I have other newer projects where I get this grayed out thing in that line $(ARCHS_STANDARD_32_BIT).
EDIT: I took a relook at this with a guru friend. Neither of us can find a linkage to i386 in our projects - Xcode is using some magic. That said, I did get a hit to i386 in a binary plist within the project, which leads me to another suggestion.
In your build settings, insure that ALL "Architectures" are $(ARCHS_STANDARD_32_BIT).
If that does not work, we suggest that you look at the compile and ld lines of your build when you select iPhone 5.1 Simulator in the scheme menu - to see if in fact its i386,
Another idea - move all your schemes and user settings to a save folder somewhere (with the project closed), then reopen and recreate a scheme. Now try again. There is no reference to i386 in any of my project.pbxproj files, so our suspicion is that this is somehow related to the scheme setting for the target device.
Good luck!
I've solved changing in both the project and target build settings the key "Build variants" from "armv7" to "normal"
in addition to deleting all the files in this directory
Users/your_usr_name/Library/Developer/Xcode/DerivedData/
i restarted my mac and it worked fine (restarting xcode and the simulator didn't cut it for me)
I was running into this same problem. In my case, it appeared to be that I had changed the Bundle Name for my multi-target project instead of the Product Name. Once I corrected that by editing the Project Name correctly and then setting the Bundle Name back to ${PRODUCT_NAME} it would run in the simulator again.
This may not be the answer for everyone, but it does appear that product naming errors (special characters, spaces, etc.) are a contributor for many, and that's what drove me to review the renaming that I had one.
I was facing the same issue with my project. Here's a brief explanation of the situation and my resolution. This may or may not work in your case.
I work at a place which has multiple iOS projects going. I recently had my system upgrade to Mac OSX 10.8 and Xcode 4.4.1. I was working on a project that was originally built on Xcode 4.1 for iOS 4. Since Xcode had iOS 4 simulators until 4.3, the project built and ran fine on all simulators. In Xcode 4.4.1 however, I did not find iOS 4 simulators and there is no easy way to install them either, which is why I was getting the "Cannot run on selected destination" error. Here's how I got my project to run.
Check under Build Settings > Architectures and set Architectures to Standard (armv7) or ${ARCHS_STANDARD_32_BIT} for all your profiles.
Set Base SDK to Latest iOS(<ios version #>) 5.1 in my case.
Set Build Active Architecture Only to NO for all profiles.
Set Valid Architectures to armv6 armv7 for all profiles. You may have to add either depending on what is already available.
Set iOS Deployment Target to iOS 5.1 (in my case) .
Make sure you have the same target under Deployment Target under the Summary tab of your project.
Clean and Run and cross fingers !!
In my case, the problem occurs after removing whole Resources folder, copying Resources folder from other or old project over current one then adding back that folder.
I solve the problem with the help from Analyse tool: after analysing, it warms me about Info.plist inside "Copy Bundle Resources".
Simply go to Copy Bundle Resource (at Build Phrase tab) delete Info.plist, then restart Xcode, clean and build. My project is back to normal.
Hope that help someones :)
I think a lot of these solutions force a full rebuild, which is what solved this for me.
I did Product => Clean, and the problem went away.
For me this worked:- Check all you product references are consistent in the settings and plists. Also check the product name does not contain any SPACE or other "illegal" characters.
try to rename your project. I solved by this way.
Judging from the responses this type of error has many potential sources, so here is my own (admittedly careless) version of the mistake (and simple solution):
XCode project Build Settings can be set at two levels: Project level, and Target level. For those less familiar, target level is where you have your executable app, and often other items like a dynamic library build.
In Linking section of Build Settings there is a option for Mach-O Type, where you can set Executable, Dynamic Library, Static Library, etc..
I was having trouble preparing a dynamic library, was scanning over the build settings for the project and saw Mach-O was blank. So I set to dynamic library. I then went on and reviewed a few more things and forgot I'd made this change. But I didn't realize I was at the overall Project Level, not the Target level for the actual dynamic library. This changed all target Mach-O settings to dynamic library.
And of course the executable target didn't like being treated as a dynamic library, and I got the OP's error message.
Setting the executable back to executable Mach-O at its target-level build settings fixed everything. Annoyingly the project-level setting still said dynamic library, but with correct target-level settings all worked fine.
Silly I know, but since a couple of the more drastic solutions listed above would have indirectly solved for this error I thought I'd share in case someone else had made the same mistake!
The way I solved this error was by a adding dummy function to my project. My issue was my app had no code of its own, only linked-in code.
I have an unusual situation with two projects: one "App" parent and one "Engine" child. All the compilable code is in the child and the parent simply links with the child, copying a ton of App-specific resources into the project.
Apparently this saddens Xcode, resulting in the above error.
My solution is adding this C function / file to the App project:
int workaround_for_xcode_reporting_cannot_run_on_selected_destination(){return 0;}
I restore the data from the time machine. Notice this is the exact same data that has been stored just 1 hour ago. The problem started yesterday. So it should be the EXACT same data.\
Yet it works.
I tried everything metioned here. Nothing worked. It seems that I somehow imported the Info.plist twice. To fix it I selected the project and pressed the "Validate Settings" button. Afterwards it works for me.
After a half day of experimenting, I think this means that the debugger can't find your executable to launch. I think this is an important distinction from the prior answers because its an underlying cause, that can have a lot of symptoms. In my case it couldn't reconcile the apps Info.plist for a custom build where we were copying the plist for the build. I changed the build setting to the Alt-Info.plist for AltDebug and that fixed it. Also meant no more copying.
Your underlying cause might be different, so the key takeaway is think about why Xcode might not be able to find your built app.
You'll be happy to know this problem has a very simple solution. Select Info.plist in your project navigator tree and make sure it is not assigned to a target. I have confirmed this is the correct solution. If building for iOS 6 or earlier you may also need to add armv6 to supported architectures
I had this issue after upgrading to Mountain Lion and XCode 4.4.1 for an OSX project.
To resolve it, I had to upgrade my deployment target to 10.5 or higher; it was set to 10.4 and up.
You have to find in the "Activity Monitor" the Xcode process and kill it! I just did it to solve a similar problem!
I've got this problem after accidentally removing the Resources folder, when I added it again to the project, Bam !
I'm also running Mountain Lion and XCode 4.4 !
trying to find out what's causing this, but it seems to be reproduced when you delete then add the info.plist file ! can someone confirm that ?
I had the same problem after two things happened:
I upgraded to Facebook SDK 3.1
I updated my OSX (with a minor version update)
The only fix worked from me was adding armv7s (mind the "s" in the end!!!)
Like was suggested here:
https://stackoverflow.com/a/12540654/531527
Yet another variant solution: after trying just about everything in the list above, I fixed this by addressing a warning that the TestFlightSDK1 path could not be found. To do so, I deleted the relevant path from Header Search Paths (Build Settings>Search Paths) and removed the TestFlightSDK, and now things run just fine.
I had this from beginning and it looks like it is a problem that the emulator can not handle virtual smartcards. Unfortunately I ended up just using my Android phone connected via USB.
Remove Info.plist from the Copy Bundle Resource build phase.That worked for me!