I am having a rather strange issue in Xcode on one of my projects.
When I start to write my code, I am used to the auto-completion suggesting numerous entries for me. For some reason, since yesterday, this has stopped working. I now get strange auto-completion entries such as "and", "the", "Andy", "MyCompanyName" etc.
This never happened before and so I am confused as to why it has occurred now, and only on one of my projects. I searched this site for quite some time for any fixes and I've attempted to clean Derived Data, quit Xcode, delete the workspace and user files from the Xcode project and restart, but after doing so, the auto-complete works for a while, then breaks again after about 30 seconds of coding.
I can sometimes see auto-complete solutions, but just plain text (no class indicators), then other times it stops working entirely.
Has anybody else experienced anything like this and could provide some solution?
I suffered for a long time with a project that kept losing auto-completion and syntax highlighting. Deleteing the Derived Data folder and restarting Xcode would fix it temporarily, and eventually that almost became muscle memory. My problem seemed to be exacerbated by using a workspace that contained multiple projects, many of which were dependant on each other. It turns out the problem was with the clang indexer. The project would compile cleanly, but looking at the output from the indexer it was littered with errors. Fixing ALL these resolved my problems.
BEFORE DOING ANYTHING: make sure ALL the targets in ALL the projects in your Workspace compile cleanly. That's without ANY warnings. This was a big failure on my part - I had old targets that just didn't compile cleanly. Some of these were unused and could be deleted, others were non-ARC that used modules in targets that had been converted to ARC (converted those targets too), and some just needed the code fixing.
Once you've resolved ALL those problems, the first thing we need to know is where the indexer is failing, by doing a complete index of your project.
First, Make sure Xcode is closed, then turn up the indexer warning
message level by entering in the Terminal:
defaults write com.apple.dt.Xcode IDEIndexingClangInvocationLogLevel 3
Then find the Derived Data folder for your project/workspace (probably ~/Library/Developer/Xcode/DerivedData/your project name-some gibberish), and delete it (but keep the Derived Data folder open because you'll probably have to go back and do this a few times.
Next, open the Console app and click Clear Display, and set the filter to "IDE" to only show the messages we're interested in.
Finally, open Xcode and the project/workspace that's causing your problems, and you'll see the console start to fill up with messages.
To look for errors, change the Console filter to "error:" - our aim is to reduce these to zero.
The majority of errors I found were missing header files. Xcode itself seems to be smarter than the indexer. It seems to be able to find and include header files from other projects that the indexer can't.
So, anywhere you see "fatal error: 'somefile.h' file not found", make sure you add the path of that file to the User Header Search Paths in the target's build settings. The best way I've found to do this is to double click on the field to get the popup, and drag the folder from the finder into it. This adds a new entry, but assuming it's in the same workspace, it adds a relative file path (this is important in case you move your workspace folder in the future). If you've got multiple targets for the same project, you can set the search path at the project rather than target level, and set the target search paths to $(inherited).
You might have similar problems with Libraries or Frameworks - again, update the appropriate search path.
Once your fixed some errors, close Xcode, clear the console, delete the project's Derived Data, open Xcode and let it index again.
Repeat until all your errors are gone.
Once you're in this good place, code autocomplete and syntax highlighting should work like a charm :)
Still happens to me occasionally on Xcode 4.3.2,
I simply do this:
Xcode > Organiser > Projects > Select your project > Derived Data > Click the delete button
This also deletes the indexing. I then usually restart Xcode and it starts re-indexing, and I get my syntax highlighting and autocompletion back again. (I don't even always restart Xcode - but an excuse to have a break from starting at a screen for hours is always a good thing for your glazballs!)
It happens that rarely, that this is relatively painless.
Most of the time I run into this problem deleting the DerivedData fixes it for me, but it one case it didn't. Turns I failed to connect the source file I created to any particular target. Once I connected it to a target source highlighting started working. If other solutions don't work, this might be your issue.
Search for 'GCC_INCREASE_PRECOMPILED_HEADER_SHARING' in build settings
and change it to YES. - This worked for me.
Its really embarrassing. By mistake I took off the Check mark in the Xcode Preferences> Text Editing> Code Completion and I tried every possible solution of that.
Please check this preference also before digging into any other solution:
You may be able to fix this problem by:
Commenting out all entries in the project's .pch file (normally when you do it, Xcode will pick autocompletion now)
Cleaning the project
Uncommening .pch file back
Rebuilding project
Now you should be able to see correct syntax highlighting and auto completions should be correct.
What the hell was that? I was not receiving any File not found error from the compiler. Fixed that one by removing some missing file links from UnitTest and UITestTarget from Compiler Sources on Project's Build Phases.
Deleting only the Derived Data of the project that is failing is not enough
I had to delete all Derived Data of all projects, did a Clean project and restart Xcode
Amazing
Related
I just upgraded to Xcode 10, and I suddenly face this error when I try to build, any ideas how to fix it? I tried cleaning derived data, but without any luck.
If you use CocoaPods, click Xcode menu file -> Workspace Settings , And click Build system choice Legacy Build System
If you not use CocoaPods, same of top , select Project Settings
If your app is generating the error related to the multiple .app files just like mentioned above in question then removing the .plist files from "Copy bundle Resources" WILL NOT WORK.
If the error is related to .app file then follow the following steps.
Select the Target.
Go to Build Phases tab.
Remove the items listed in Output Files
Compile the code if it compiles successfully then not follow the next steps.
If code does not compile successfully and Xcode may give you an error related to "Library not found". Then add the missing library in General Tab in Linked Frameworks and Libraries that Xcode mentioned in the error.
Keep adding these libraries (that Xcode ask through compile errors) in Linked Frameworks and Libraries until the code compiles successfully.
Hope this helps.
You can try to change the build system to Legacy,
File > Workspace Settings > Build System > Legacy Build System.
I also faced this issue in xcode 10 but it was because of adding the same framework in main project + other extensions (watchkit or siri extension etc).
I added ObjectMapper in podfile for my main project + for my extensions. When I compiled it gave me an error that multiple command produce and also shows me which framework is causing this issue. Now its working fine for me as I've removed it from my extensions I wasn't using it in my extensions.
Don't know about your issue may be you can check your podfile.
If this is CoreData related. The issue is that you are trying to generate the NSManagedObject subclass but you need to set the 'CodeGen' option to Manual/None. This option is defaulted to Class definition and this would regenerate the code thus creating this issue.
i encountered this issue as well while working with CoreData.
in my .xcdatamodeld file, it came down to the fact that, during the creation of my various Entities, i had copy and pasted one multiple times (thinking i was saving time because various properties were similar enough that i thought this was a good idea).
the resulting Build error Xcode 10 - 'Multiple commands produce' occurred because i forgot to check and make sure the new Entities were set to their own unique corresponding class to match the new Entity in the Data Model Inspector pane.
unfortunately, it took me two days to figure out the original Entity's Class Name was still in place.
so lesson: careful when you copy/paste/duplicate Entities in CoreData.
(... i guess :0} )
some time saver. oops! hope this helps someone.
I had this same issue with Core Data entity class. I had forgotten to select Codegen Manual / None because I do not allow mine to be autogenerated. So I had a class in place and also it was trying to generate one.
From the beginning of my project, I use a custom framework, let's call it "custom.framework". But there was a bug in this framework and now I want to use another version of the "custom.framework".
At first, I simply removed the "custom.framework" file from my project and added the new one. But nothing changed, the bug was still there.
After multiple tries and hours, I understood that Xcode add the old version in memory and used this one instead of the new version. I know it because in the new version I added a method and when I cmd+click the class I've add the method into, it's not there and the file's path is unavailable.
Searching through the web, I tried to change some version parameters to my framework projects: Compatibility version, Curent Library version, Framework version. But this didn't change anything to Xcode which keeps using the old version.
I also tried to make the framework's project as a sub-project and add resulting framework as a dependency to my target. It worked well, but as the framework's project is on a separated remote git repository, I don't think this is an acceptable solution.
So my last try was to build a "custom2.framework", to force Xcode to use the real file and not some cached version. But again, it doesn't work and when building I get errors telling me that all my classes in custom2.framework are duplicated symbols of its cached version of "custom.framework".
So my question is simple: how can I finally tell Xcode to deleted its cached old version and let me use the file I gave him? I already tried to delete my project's derivedData but it seems cached frameworks aren't there.... I'm so desperate :(
Edit: Here are 2 screenshots to illustrate the issue
First screenshot is the path as shown by Xcode when I opened the file from the .framework object in the project navigator.
Second screenshot is the path as shown by Xcode when I opened the file from a cmd+click to a "DCEquipmentManager" in code.
As you can see, the framework linked with the code is not the framework in the project.
it seems problem with binding in new framework, your project still linked with old framework files.
try to remove all files and folder related to your "custom.framework and also remove path for that framework from project setting--> build setting --> search Path
Then after Drag and Drop Your "custom.framework" files in project.
it works for me.hope it resolve your problem.
Please try to clear derrived data:
Window -> Organizer
at the right side you will see projects list. Find your project and tap on it. I the top part of window you will see button delete in front of Derrived data, tap on it.
I guess it will solve your problem.
It might sound silly, but sometimes restarting XCode or the whole machine fix things.
Did you remove the old framework from Build Phases --> Link Binary With Libraries?
Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.
First lets say something upfront. The build stage is a(are) command line tool(s) that is managed by Xcode according to your Build Settings.
So when Xcode doesn't find your Framework - the Build System will usually also not find it. This forces you to act but may end up in confused Xcode to catch an older reference.
Yes it may happen that the Header Xcode is pointing to is correct but the build system still uses an old copy somewhere. An outdated copy can dangle around literally anywhere depending on the steps you took before.
It (Xcode) assumes where it is located but the Build System still uses another version or the Search Paths just pointing in the wrong Locations even if they are visible to you and even your Framework icons are visible in the lists. So when you erase the last build you actually only force Xcode to rebuild from the known arguments, the settings stay the same, the lists stay the same. Even restarting Xcode does not change anything, the problem persists.
Ergo: Compiler Instructions, Xcode settings and Build System settings don't match what the code tells with #import <NAME/Name.h>
So you will check at least those 6 stages again:
Is your Framework Header File published in your Framework project?
are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?
Is your Framework in linking list?
Is your Framework in Embed Framework list?
Does your framework appear in the Framework Group Folder in Workspace/Project Browser? (usually the very last Group Folder in the Browser below all your other files)
Is my Folder Structure correct?
At least 1 to 4 must be right otherwise it will fail.
Here a random list of common causes
Framework is located outside your Source Paths structure
Structure got changed after you added it to the project
You use Workspace's where Framework development and Final Application can appear side by side but you assume Xcode uses this to change its Search Paths
The contained build settings are misleading from former drag and drop operations, ending up tricking Xcode in the "wrong" corner. In this case recreating a project is just one of the possible ways to fix it but not the solution.
Also dragging a Framework into your Project > General or separated in Build Phases > Link Binary list or Embed Framework lists does not make Xcode aware of the wrong Build Settings.
The Linking works, embedding works, but compiling does not. The Header information is still missing.
The solution must be to correct your Build Settings.
As mentioned above Build System and Xcode are two different things. In particular only setting the right Framework Search Paths will solve those issues, even if you managed to kick your derived data manually.
Erasing Derived data?
Derived data is the place where precompiler collects data to compile. So it can be seen as expression of what all the settings are told to do. Erasing it does of course not change the settings but may fix inconsistencies related to former Build Settings. It would erase the derived data and rebuild from the Build System Settings you gave.
Correcting Linking?
Also Linking is not the same as making Xcode aware of the desired Headers. Linking is for your final Product to know where Symbols are to call on them at runtime, it does not change Framework Search Paths and System Framework Search Paths, they stay the same as given.
But it is not wrong to start fixing first with
Product > Clean Build Folder, it forces your build to parse all and compile all again on the next Build.
When the troubles come up because of folder structure in parallel or Frameworks are simply placed outside the Source Directory then you must point to them directly or relative.
Most likely you should place one extra entry in your Framework Search Paths like $(SRCROOT)/../Yourframeworksource/build/Debug. expression to point to relative higher folder structure.
Needless to say that a Release Build likely needs another entry ending in "/Release".Hint: Well you can have different Search Paths for different Compile Schemes..
This works particular good after you cleaned Linking List, Embed Frameworks List and then also check the very last Group Folder "Frameworks" for double entries to drag and drop a fresh Framework reference in there.
How to know if leading /../ will fix it?
Click on the dropped Framework Icon inside the workspace Framework Group Folder (lower most) while your Project is the active selected to work on, now watch for the relative Path information on the very upper right side of Xcode, if there is some /../ you know you need it as well.
Sorting of Framework Search Paths
play a role of course, just the same as #import/#include rule sorting matters.
Remember the first found, first wins rule because often we use #import that works different then #include but ignores second attempts to declare. This leads to once wrongfully declared headers to hide corrected declarations later on in parsing that share the same filename or define rules
#ifndef xyz
#define xyz
// all your code here.
// a second read attempt would be ignored
// a second read is hidden also when you use #include then.
#endif
So you can sort those entries either by code and/or in the build settings if needed because of course it matters what is declared before other declarations depend on it.
I followed this excellent tutorial to set up to build a framework I'm building for an iOS app.
http://spin.atomicobject.com/2011/12/13/building-a-universal-framework-for-ios/
I have everything working pretty well except for one little detail. Sometimes, it can take several attempts at building the project before all the header files are copied into the final framework.
Occasionally I'll hit "Build" and the Headers folder for the framework is completely empty at the end. Sometimes it will have 90% of the headers, but not all. Once in a while I get lucky and they all seem to be there.
What would cause this and how do I correct it?
Update:
So far my only solution is to just keep rebuilding the framework and eventually it copies all the headers the way I expect it to. Still looking for a better answer though.
One of the workaround I use to get around this problem is dirty (i.e. double-click open file, press spacebar & delete key on keyboard and save/Cmd+s) all the 'add copy files' before I build (Cmd+B).
Another workaround - Build the project twice and on second build, the files get copied.
Anyone have real cause/solution of this issue?
I’m not certain that this is a RestKit issue, and I’ve tried reinstalling RestKit via CocoaPods many times, but eventually I get this error:
<RestKit/RestKit.h> file not found
Everything compiles fine, and RestKit works. I've set the header search paths to $(inherited), just as with other linker flags.
This is unfortunate, because now the autocomplete for those classes isn’t working.
I’ve tried cleaning, deleting derived data, and restarting Xcode, all to no avail.
I came across this question when having the same problem, but I had a very different solution that worked right away.
For whatever reason, sometimes a project seems to lose track of some settings that relate to CocoaPods. In my case it was triggered when I downloaded a project from a repository that had been set up by someone else - even running "pods install" again did not remove the compilation error.
I finally ran across the solution somewhere, the project needs to make use of Pods config files for your target. Go into your project settings "Info" tab, open the "Configurations" section. Expand both Debug and Release, check to make sure that for your project have the "pods" configuration set. If not, click on the drop down and select "pods" for Debug and Release - now compile and the error should go away.
Here's an image showing exactly what part of the XCode configuration I'm talking about.
I believe the issue is more related to Xcode than the cocoapods themselves. I've seen this issue on other pods I've imported as well where they don't autocomplete the headers. As Keith said in the comments, you should be able to import the header you need and the rest of the code should autocomplete from there.
THIS QUESTION REFERS TO RESTKIT 0.9.x.
IF YOU ARE NEW TO RESTKIT CONSIDER USING THE NEWER 0.10.x branch.
I recently inherited a project that uses restkit (restkit.org). I have started using a branch (402-new-build-process) that is more compatible with xcode4.2.
My project an all the example projects build and run, but when it comes to Archiving an app the build fails:
/Users/AUser/Documents/SubFolder/stable-branches/project-iOS-client/RestKit/Examples/RKTwitterCoreData/Classes/RKTwitterAppDelegate.m:9:9: fatal error: 'RestKit/RestKit.h' file not found [2]
#import <RestKit/RestKit.h>
^
1 error generated.
I have followed the Installation Troubleshooting guide on the project wiki, but this did not work.
As per Blake's answer I am building to the DerivedData directory:
In addition I have tried setting header search to these (in many combinations [just guesses]):
"$(BUILD_DIR)/RestKit/Build"
"$(SOURCE_ROOT)/RestKit/Build"
"$(SOURCE_ROOT)/../../Build"
"$(BUILD_DIR)/../../Build"
I think all these fixes were stabs in the dark, or at least felt like that to me. I half expected to read one about getting some hair from a young virgin and burning it over the Mac.
If it compiles for you in dev but not for archive its bound to be something simple. Or at least it was for me.
My source files were not in the right place:
The search header was set to "$(SOURCE_ROOT)/RestKit/Build"
But I had simply dragged the proj file from where I downloaded it into XCode. This was never an issue when compiling for debug etc. Just when archiving so I didnt spot it for a while.
Just make sure what ever that path is to the RestKit/Build is where the actual files are.
Fixed it for me, unlike all the cross your finger fixes I've read. Like moving headers into a group etc... what a load of rubbish that was.
Good luck, hope this helps. Thanks to the Restkit team, this really is a great framework.
Jamie
I am building against the development branch and integrate RestKit as a submodule in my root git folder
+ root project folder
|--+ RestKit
|--+ <Projectname>
|--+ <Projectname>.xcodeproj
So I use the following search paths
"$(BUILT_PRODUCTS_DIR)/../../Headers"
"$(SOURCE_ROOT)/../RestKit/Build"
!!!Update to the latest version of the branch!!!
I've just built RKCatalog and RKTwitterCoreData as an archive on Xcode 4.2 without issue. I am failing due to a Code Signing issue. Have you confirmed that you are building with the DerivedData directory:
RestKit assumes that you are using a modern Xcode project building to the DerivedData directory. Confirm your settings
via the "File" menu > "Project Settings...". On the "Build" tab within the sheet that opens, click the "Advanced..."
button and confirm that your "Build Location" is the "Derived Data Location".
I can push changes that rsync the headers to a known location, but I was hoping that standardizing on DerivedData would simplify the process.
To reiterate Jamie Reynolds answer, most (if not all) of you have set your header search paths to "$(SOURCE_ROOT)/RestKit/Build", this is fine while debugging and also fine for archiving, unless of course your Restkit framework IS actually in this directory.
Like the majority of you out there, you have probably just linked to the framework from the default download directory, in which case go to finder, open Restkit->Build cmd+i to see the info and select the directory path, copy and replace "$(SOURCE_ROOT)/RestKit/Build", dont forget the brackets.
mine was "/Users/edwin-b/Downloads/RestKit-RestKit-8d0d9fc/Build" worked like a charm
I followed the steps outlined in several SO answers, and the issue ended up being a problem with the Header Search Paths. Sometime between adding RestKit in XCode 4.2 and trying to archive in XCode 4.3.1 (I had updated twice between starting the project and providing a build), a comma had been injected in the Header Search Path list which Xcode could no longer parse. As a result, the entry for RestKit's header location was:
"$(SOURCE_ROOT)/RestKit/Build",
When it should have just been:
"$(SOURCE_ROOT)/RestKit/Build"
While this didn't produce any issues building to device or sim, once I tried to archive, it caused the error reported by the OP.
Just add "$(SOURCE_ROOT)/RestKit/Build" to you target "Header Search Paths", Thanks to this answer.
I'm sure some of these are redundant, but I just spent over 3 hours debugging this thing and almost ruined my project in the process. So... Here you have it.
For the sake of your sanity, create a zip backup of your project before messing with RestKit project paths, commit all files (especially the project) to source control, cross your fingers, burn a virgin hair over your mac, then proceed.
After eliminating them one by one, I narrowed it down to this line allowing me to archive.
"$(SOURCE_ROOT)/../RestKit/Build"
Restkit is a folder at the same level as the main project folder
I'm adding this answer so I can find it later - it matches some responses above. Look in your targets "Header Search Paths" - and depending on where your restkit directory is in your project, add one of the lines specified above in Alex Stones answer. In my case, it was "$(SOURCE_ROOT)/../RestKit/Build"