Related
So I'm just coming back to programming for macOS after a few years hiatus, and have discovered the #import syntax. I created a sample program to test it out, but it's not working as my googling seems to suggest that it should.
Test project setup:
Open Xcode
File>New>Project...
Select the Cocoa Application template for macOS. Click Next
Name the project "ModuleTest", add organization name and organization Identifier. Select Objective-C as the language, check Use Storyboards, make sure "Create Document-Based Application", "Use Core Data", "Include Unit Tests" and "Include UI Tests" are all unchecked. Click Next and choose a save location. Don't create Git repository, and don't add to any project or workspace. Click Create.
In the Navigator, click on Main.storyboard.
From the Object Library, drag an AVKit Player View object onto the View of the View Controller Scene in the Storyboard.
Now at this point, we can see the symptom, which is that if you build the project, a window will pop open, but the player is missing from it, and the xcode output window shows a message such as
2016-08-16 09:07:46.465 ModuleTest[19778:4097187] Failed to set
(contentViewController) user defined inspected property on (NSWindow):
*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (AVPlayerView) for key (NSDestination); the class may be defined
in source code or a library that is not linked
This error occurs regardless of whether I put an #import AVKit; statement into AppDelegate.h, AppDelegate.m, ViewController.h, ViewController.m, or main.m. However, simply linking the AVKit.framework in the "Link Binary With Libraries" section of the project's Build Phases, solves the issue, no #import needed anywhere.
So what's going on? I thought #import was supposed to eliminate the need to manually link frameworks? Am I going through the process incorrectly? Is this happening because I'm using storyboards? Any ideas?
The problem is that there is no actual code that references the AVPlayerView. Try adding a single line of code that uses AVPlayerView and you'll notice that the error is gone.
I have recently been working to add Swift to an existing project, to get to try it out in a real-world fashion.
Upon adding a Swift source file to the project, I have no problems about getting the "Bridging Header", that is, Objective-C to Swift.
But the *-Swift.h header file that is supposed to expose Swift classes either marked #objc or subclasses of ObjC classes, is nowhere to be found :-(
I don't see any specific instructions on how to accomplish the usage of my new subclass, written in Swift, in my main app code (which is still Objective-C).
The app that I am lead developer of has a fairly large codebase (70.000 lines), so transitioning it in one go is out of the question.
Now it works.
Project must have a Product Module Name that does not include spaces.
Defines Module must be set to Yes in Build Settings, under Packaging.
Finally works. Thanks to everyone for the help :-)
I had a similar problem and found that you can only add
#import "ProductModuleName-Swift.h"
to obj-c .m files, not .h files for the umbrella header to be found
I found that I had to fix all build errors before it would generate the file.
The problem for me was that it was a chicken/egg problem, in that I didn't see any build errors until I'd actually commented out the #import statement:
//#import "ProductModuleName-Swift.h"
which revealed a bunch of other errors in my Swift code.
Once I fixed these new errors and got the source building successfully, I uncommented out the #import and bingo! The header was created and importing correctly :)
If you're like me you've probably got the header name wrong. After bashing my head for a while I looked for the file in DerivedData and sure enough it's there. On my setup (using the standard derived data folder, I believe):
cd ~/Library/Developer/Xcode/DerivedData
find * -iname '*Swift.h'
Will find it. If nothing in that folder matches then Xcode is not generating it.
I'm using Xcode Version 6.2 (6C86e)
If your project module name has spaces in it, you must replace the spaces with an underscore.
For instance, if your project name is "My Project", you would use:
#import "My_Project-Swift.h"
* The only important thing is: *
to use the defined "Product Module Name" in the target, followed by -Swift.h
#import <Product Module Name>-Swift.h
// in each ObjectiveC .m file having to use swift classes
// no matter in which swift files these classes sit.
No matter if "Defines Module" param is set to Yes or No or if "Product Module Name" Project is not set.
Reminder: Swift classes must deriving from NSObject or been tagged with #objc attribute in order to be exposed to ObjectiveC / Foundation || Cocoa ...
I wanted to add one more reason you might find an issue with this - I was creating a framework that mixed Swift and Objective-C code. I was not able to import the Swift classes outside the framework - I checked for the -Swift.h file and it was being generated but was empty.
The problem turned out to be very, very simple - I had not declared any of my Swift classes public! As soon as I added the public keyword to the classes, I was able to use them from classes inside and outside the framework.
Also of note, inside the framework (inside .m files only as another answer mentions) I had to import the -Swift.h file as:
#import <FrameworkName/FrameworkName-Swift.h>
I had the same problem. Seems like you have to adjust the settings (Defines Module and Product Module Name) before you add your first Swift file.
If you do it afterwards the "*-Swift.h" file will not be generated for this project even if you add further Swift files or delete the Swift file and create a new one.
Allow me to share my experiences trying to use Swift in an old objc project. I did not have to set Defines module to YES.
In my case I needed to manually make sure there was an objc Bridging Header. Only the generated interface header name was present in my build settings.
This lead to a MyApp-Swift.h file to being generated, but without any traces of my Swift classes.
The Apple documentation says that you will be prompted to create a bridging header when adding your first swift file. Well, I wasn't. I manually added a MyApp-Bridging-header.h file and pointed to it in the "Objective-C Bridging Header" field. That made my MyApp-Swift.h file become populated with my Swift classes.
Docs: Importing Swift into Objective-C
Here is another variation of the moduleName-Swift.h not being generated.
I decided to include IOS Charts in my project but did not want to mingle the sources in the same directory, so I placed the Charts Project folder next to my code's project folder. I dragged the Charts project into my Project's Navigator Bar and included the framework in the my project target's Embedded Binaries list in the General project settings and set the Embedded Content Contains Swift Code switch to yes in my project's Build Settings tab in the Build Options section.
My project's moduleName-Swift.h file would never generate no matter what other switches or settings suggested here. Finally, using Lou Z's method of seeking out the -Swift.h files, I saw that a Charts-Swift.h file was being generated deep in my project's xcode Build directory in Charts.framework/Headers/
The solution to using Daniel Gindi's ios-charts Swift package without including the code in my project's source directory was to add:
#import "Charts/Charts-Swift.h"
To the modules charting my project's data.
The file name is always preceded by your Target name. It is referred as Product name but practically it is the target name.
So if you want it to build for a new target be ready to expect that_target-Swift.h file.
One way to handle this is
Add a preprocessor for each of your target that is the name of your target itself (without spaces). Ex. MY_TARGET=1. Add this in Project settings->Build Settings->Preprocessor Macros for each of your targets.
If you are using a PCH file,
Add these lines in the PCH file
#if MY_TARGET==1
#include "My_Target-Swift.h"
#elif THAT_TARGET==1
#include "That_Target-Swift.h"
#endif
Advantage of using PCH file is that you don't have to include the headers everywhere.
If you are not using a PCH file, just add these same lines in a single header and include that header wherever you need to use the swift classes.
This should work just fine.
If Xcode is actually generating your -Swift.h header (deep inside DerivedData) but it doesn't refer to your Swift classes, make sure you also have a bridging header defined. The way I read the docs implied I only needed that for calling Objective-C from Swift, but it seems to be necessary for calling Swift from Objective-C too.
See my answer: https://stackoverflow.com/a/27972946/337392
EDIT: It is because of public vs. internal access modifiers, as I eventually found explained in the Apple docs:-
By default, the generated header contains interfaces for Swift
declarations marked with the public modifier. It also contains those
marked with the internal modifier if your app target has an
Objective-C bridging header.
Seconding what a lot of people have here, but adding a pertinent screen shot. Swift and Obj-C code can certainly live together. It's not an all or none game.
To access Swift files in your Objective-C, all you need to do is add this call to your Obj-C file (in the .m / implementation file):
#import "{product_module_name}-Swift.h"
(Where {product_module_name} represents the product module name of your project). Rather than try to guess your product module name or figure out corner cases with spaces and special characters, just go to the build settings tab in the project and type in "product module name" - the inspector will reveal yours to you. Mine was something I did not expect it to be. Check out this screen shot if you're confused.
And to get Obj-c code working in Swift, you just need to add a bridging header file and import the relevant Obj-C headers there.
This answer addresses the use-case where you may already have some Objective-C code that calls Swift classes and then you start receiving this error.
How To Fix Issue
The following steps ultimately resolved all of the issues for me. I read above someone mentioning the "chicken and the egg" and it is exactly that concept which led me to this procedure. This explicit process shows that one has to remove any Objective-C code referencing Swift classes until after the header is generated.
Comment out the #import "ProductModuleName-Swift.h" statement in
your Objective-C implementation file
Comment out any references in the Objective-C implementation file to
Swift Classes
Clean & Build
Resolve all errors/warnings
Remove the comment on the #import "ProductModuleName-Swift.h" statement
Clean & build (successfully or fix any remaining errors, verify that you are not referencing any Swift classes in Objective-C at this point. If so temporarily comment these out)
Verify that "ProductModuleName-Swift.h" is generated by Cmd-Clicking
on the class name of the #import "ProductModuleName-Swift.h" statement
Remove the comment on the code referencing Swift classes in the Objective-C implementation file.
Clean & Build as normal (the "ProductModuleName-Swift.h" should be
generated and your Objective-C code referencing Swift Classes can be
used as normal)
Nota Bene: The answers about changing spaces to underscores and the Defines Module to YES as given above still applies when performing this process, as do the rules specified in the Apple Documentation.
Bridging Header Path
In one error, the file ProductModuleName-Bridging-Header.h was not being found during the build process. This fact generated an error
< unknown>:0: error: bridging header
'/Users/Shared/Working/abc/abc-Bridging-Header.h' does not exist
Closer inspection of the error indicated that the file would never exist at the location described because it was actually located at (a wrong path)
'/Users/Shared/Working/abc/abc/abc-Bridging-Header.h'. a quick search of the target/projects build settings to make the correction manually and the abc-Swift.h file was again auto generated.
Ok, here are all the things you really need!
1.Remove all the swift files you have added, and compile the code, without any errors.
----------
----------
2.Go to the "Projects" build settings, and set the product module name.
Project must have a Product Module Name that does not include spaces.
----------
----------
3.Defines Module must be set to Yes in Build Settings, under Packaging, in your project, and not target!
----------
----------
4.Now create a swift file or a view controller, in file-> newFile->
----------
----------
It will ask to create a bridging-header, allow it to make one.
If you have declined it once, you will have to manually add a -Bridging-Header.h
5.Add #objc in the controller, to tell the compiler that there is some swift file, which needs to be exposed to ObjectiveC
----------
----------
6.Build the project and import #import "-Swift.h" in any of the objectiveC controller, and it will work! You can Command-click on it to see the actual file!
----------
----------
Hope this helps!
The most important thing is that This file is invisible!!! At least it is in Xcode6 beta5. There will be no such file named "YourModule-Swift.h" in your workspace. Just make sure you have module name and defines module set to yes, and use it in your Objective-C class.
You have to import a header in Objective-C classes, which is:
#import “ProductModuleName-Swift.h”
It is automatically generated, on the reference it says "Any Swift files in your target will be visible in Objective-C .m files containing this import statement."
An actual file in the project is not created ([ProductModuleName]-Swift.h). Cmd + Click on the import either generates it on-the-fly (and in-memory) so you can see how the linkage is done, or opens a file somewhere in some Xcode cache dir, but it's not in the project dir.
You need to set Defines Module project prop (in target's Build Settings) to Yes and if your module name has spaces or dashes - use _ in all imports of the [ProductModuleName]-Swift.h file.
You can import it in all .h and .m files where you use swift types or you can import it in the .pch.
So if my Module (project) is named "Test Project", I would import it like this, in the .pch file of my project (just there):
#import "Test_Project-Swift.h"
Just a heads up for anyone who used "." in there project name. Xcode will replace the "." with an underscore "_" for the Swift version of the bridging header file. Oddly enough the Bridging-Header.h that is generated does not replace the periods with underscores.
For example a project with the name My.Project would have the following Bridging Header file names.
Bridging-Header.h (Autogenerated)
My.Project-Bridging-Header.h
Swift.h
My_Project.h
I hope this helps anyone who used a period and was stuck like I was. This file can be found at the following location.
Macintosh HD/Users/user/Library/Developer/Xcode/DerivedData/My.Project-fntdulwpbhbbzdbyrkhanemcrfil/Build/Intermediates/My.Project.build/Debug-iphonesimulator/My.Project.build/DerivedSources
Take care,
Jon
Project must have a Module Name not including spaces.
Defines Module must be set to Yes in Build Settings, under Packaging.
commented out the #import statement:
If still you are having error in importing "ProductModuleName-Swift.h" then
//#import "ProductModuleName-Swift.h"
which revealed a bunch of other errors in my Swift code.
Once I fixed these new errors and got the source building successfully, I uncommented out the #import and bingo! The header was created and importing correctly :)
I found a trick that always works on me.
Create your #import "ProductModuleName-Swift.h" in your appDelegate.h file and in your ProductName-Prefix.pch file. If you don't have it in xcode 6 you can create it with this way Why isn't ProjectName-Prefix.pch created automatically in Xcode 6?
Command+shift+k to clean your code, if you receive an error about your "ProductModuleName-Swift.h" delete it from appDelegate.h file.
Clean your code again. Now everything will work like a charm
If you receive again error about the "ProductModuleName-Swift.h", now create again in appDelegate.h file and clean your code again.
Do this work (delete and create the "ProductModuleName-Swift.h" from appDelegate.h file and clean your code) everytime you receive this error to silent it.
I Found this solution
Create SwiftBridge.h
put #import “ProductModuleName-Swift.h”
Make this .h file public (important) Select the file -> In Show the file Inspector (right bar) -> Make it public
Now you can
#import "SwiftBridge.h"
instead of ProductModuleName-Swift.h
This's a workaround solution, for the next version of Xcode I think this problem will be solved.
Good luck
If you were able to build a project before, with no issues related to “ProductModuleName-Swift.h” not found error, and now you are getting that nasty errors again, the reason might sit in your recent changes.
For me this was by (accidental) incorrect .swift file encoding. Reverting changes and bringing the back manually, does the job.
I was having a hard time determining my module name/objective-c's import of swift's headers. I did read a lot of articles here too.
But the definitive answer for your project name with all its included special characters (be it '.' or a numeric or a space) - you can find the text that will work for you in the "Product Module Name" under the target's Build Settings.
For example my target name started with a numeric - "1mg" and the field mentioned above showed "_mg" as my module name.
so I used #import "_mg-Swift.h" and it worked.
This may be an obvious point (maybe too obvious), but you must have at least one swift file in the project for the header to generate. If you are writing boilerplate or config code with the intention of writing swift later the import won't work.
In my case I had to set the deployment target to at least “OS X 10.9” and the -Swift.h header was automatically generated. Keep in mind that you can get a lot of deprecation warnings when you change the deployment target version, especially when you have an older and very large Objective C code base. In our case we also had a lot of work to do in XIB files & view classes.
I had to delete WatchOS2 swift code from my Objective C project. And only after that XCode offered to generate -Swift.h
I had similar problem but my project was compiling before and suddenly got error after few files code change. It took me while to figure out why I am getting 'File not found' error for myproject-swift.h file. The code changes I had done had some errors. Xcode did not point put those error instead all time showing the 'File not found error'. Then got copy of previous version code and I compared with new code and merged file one by one. After each file merge complied the project to find the error. So bottom line is if you have error in your code Xcode may just display 'file not found error' for myproject-swift.h file. Most likely you have compilation error in your project. Clean those error and it will work.
If you're using something like Cocoapods (and working out of the workspace rather than the project) try opening the project and building it before opening the workspace and building. YMMV.
Sometimes you just need to unset and then set again the target membership on the obj-c .m file.
I'm helping on an iOS project with lots of methods and definitions common to many different classes in the AppDelegate. So, in each of those classes, in the .h file, I use #import "AppDelegate.h". This works fine until I need access to one of those classes that already imports the AppDelegate into another class that imports AppDelegate. At this point, I get a Duplicate Interface Definition error for AppDelegate.
Ok, so that seems fair. I'm already importing AppDelegate into a file that I'm importing, so AppDelegate is getting imported from two different places. So I remove the AppDelegate line, and everything is fine.
But what happens when I need to import two classes that both need to import AppDelegate?
I have a very specific problem that I'm trying to wrap my head around, and I know it is being caused by something that has to do with this, but I'm not sure what. So I'm hoping if I figure out how I'm supposed to be handling this sort of importing, and sort everything else out, and hope that this solves my problem. So to put this in more concrete terms:
I have ClassA.h, ClassB.h, and ClassC.h. All have #import "AppDelegate.h". When I need to use #import "ClassB.h" in ClassA, I remove the #import "AppDelegate.h" line from ClassA. Everything works smoothly. But what happens if I also need to #import "ClassC.h" into ClassA, and but ClassB and ClassC NEED to have the #import "AppDelegate.h"?
EDIT:
I tried the exact scenario I described above in a clean project, and it built fine, so there is something else at play. But what I can say with certainty is that when this issue came up previously with this project, it was a duplicate interface definition of AppDelegate, and when I removed the #import "AppDelegate.h" line, the error went away, and I still had access to the AppDelegate.h methods and enums through other imported files.
The best prevention and cure for this is to follow some guidelines on when to import from a header file. As a general rule, never import from an Objective-C header except in these cases:
You need to extend a class declared in another header.
You need to declare conformity with a protocol declared in another
header.
You need to refer to a non-class, non-protocol type defined in another header in the public methods and / or properties. To refer to protocols and classes, forward declare them with #class or #protocol, like #class ClassFromOtherHeader;
Every other #import should go in your implementation. My recommendation is to start moving all your #import statements out of headers and into the implementation files according to these rules. Start with the files you think are at the root of the problem and move outward. This will fix your problem and give you the side benefit of clearer code and faster build times.
For me none of the above answers were helping, nor did the answer given here work.
What fixed it for me was closing Xcode, going to ~/Library/Developer/Xcode/DerivedData and deleting all of the derived data associated with this project. After that I reopened the project and it was working fine.
Hope that helps someone!
In my case, none of the solutions mentioned fixed the issue. Xcode was reporting a duplicate interface for a class I rewrote in Swift. Somehow it kept pulling in the Objective-C header file for a class that wasn't directly referenced in the project.
I opened the Terminal, cd into the project directory, then ran the following to track down any files that were including the class header:
grep -nr ProblemClassName.h .
It turned out that the bridging header included an obsolete file that wasn't even referenced in the project navigator. That in turn was importing the header files referenced in the Xcode error, that were also not included in the Xcode project navigator. Now I know to not rely only on the Xcode project navigator for files referenced by the error.
tl;dr Double check the bridging header to ensure that all files that are imported there should be there and are not importing headers that are in-turn importing the problem headers.
I found that a project had a subproject and instead of referencing the includes in the subproject with the proper syntax:
#import <SubProject/Filename.h>
It was directly importing them
#import <Filename.h>
This was only possible because the path of the subproject was included in the "header search paths" of the main project - which is the wrong way to do business. So I deleted it from there.
The subproject should copy the needed included files in its "build phases - copy files" section (which was already happening actually), and the proper form of import that uses the Subproject/Filename.h syntax should be used.
Fwiw I started getting this seemingly at random - for me the fix was to do Product->Clean and it magically went away.
For me, I forgot to include parenthesis in interface definition in m file.
I keep getting this for situations that are patently false, related to objective-c categories.
NB: this was working fine, then stopped working overnight.
It's as if Xcode is fundamentally broken in it's ability to "read the file system", and it's driving me nuts. Any ideas on how to force it to ... read the file system ... would be appreciated.
e.g.:
Start Xcode, write a file, import it, using Xcode autocomplete.
cmd-click on the import line, and it jumps to the header file
A few builds later, Xcode flags a Warning:, e.g. "Class method '+stringFromCGPath:' not found (return type defaults to 'id')"
Now when you cmd-click on the import line, Xcode flashes up a dialog "Symbol not found" (world's worst dialog box? doesn't even have a confirm, it flashes and vanishes)
If you run the app, it crashes on that line, saying the selector not recognized
Then, to prove how FUBAR Xcode is:
Quit Xcode, restart
Cmd-click is working again
...but the Warning is still in place, and the app still crashes
After a few seconds, cmd-click stops working
NB: things I've checked:
The file is in the project folder? YES
The .m file is included in the Target? YES
The .m file is in the list of files to compile? YES
Do a CLEAN ... then a BUILD? YES
UPDATE: an example header I'm trying to import - that I have been successfully importing for months, and worked fine in hundreds of builds, and I have NOT changed (confirmed using SCM):
#import <Foundation/Foundation.h>
#import "CGGeometryExtensions.h"
#interface NSString(CGPath)
+(NSString*) NSStringFromCGPath:(CGPathRef) path;
#end
UPDATE2: actually, this doesn't crash at runtime - it was crashing because there was a typo in the call to "NSStringFromCGPath:" (one letter was lower case when it should have been upper case). But this was hard to see because of XCode's claim that the whole header file didn't exist - even though, as noted above, the IMPORT line was auto-generated by Xcode.
It sounds as though you may have problems with the indexer. Have you got multiple targets in your project, or multiple projects in a workspace? If so, make sure they all build completely cleanly - a failure indexing one target can mess up code completion on another.
You might also try deleting your project's DerivedData folder
I am trying to run my cocos2d application and facing this error, as I have recently upgraded my sdk to 4.2 and my cocos2d to 0.99.5.
I tried to clean my project even change the Target ios Deployment but error remains the same. Also rename the className aswell in order to avoid duplication from Library classes names of cocos2d.
ld: duplicate symbol _OBJC_METACLASS_$_MenuSceneNew in
/Users/umaidsaleem/Desktop/functionalityTest/build/Debug-iphonesimulator/libcocos2d
libraries.a(MenuScene.o) and
/Users/umaidsaleem/Desktop/functionalityTest/build/functionalityTest.build/Debug-iphonesimulator/functionalityTest.build/Objects-normal/i386/MenuScene.o
Another rather simple thing to check is that you did not accidentally #import a .m file instead of a .h header file.
Happened to me.
You are linking the file MenuScene.m twice. You apparently have it in a static library and also in your main application.
Another reason for this, for those out there who did the same as I just did, might be that you re-created a managed object class. By doing that and choosing another group in the project structure, you accidentally create another reference to the same files.
I ended up with two references for header and implementation in both the root of the project and in my model group. Removing the topmost references to .h and .m files got rid of the linking failure.
Sometimes Core Data inserts AnyProjectNameModel.xcdatamodeld to the Compile Sources of the Build Phases. Check it and delete it and everything is run again...
The error message just indicates the generated ManagedObjects...
The correct place for the AnyProjectNameModel.xcdatamodeld is the Copy Bundle resources in the Build Phases.
Check the Compile Sources of your target and see if a class.m file is included twice
A stupid mistake that I made was that I named my #implementation the same as my superclass.
In the .h
#interface Subclass : Superclass
#end
In the .m
#import "Subclass.h"
#implementation Superclass
#end
None of the regular suggestions from google seemed to help, so if someone is as crazy or tired as I am (maybe a healthy mix of both), make sure you haven't duplicated an #implementation!
In my case this was happening because of Xcode automatically generating my NSManagedObject class, which then clashed with my manually created NSManagedObject class. In this case you can set "Codegen" to "Manual/None" in the Data Model Inspector for your newly created Entity.
Another thing to check for the double linking - its possible to have the same file in two different places in the file list on the left. Then the compiler compiles and links it twice.
This happens when playing with organizing your file hierarchy, for example.
You don't have to be making a library or anything fancy - just drag a .m in to two different locations in the project tree.
Remember to only remove the reference to one of them, no file trashing is needed.
To me, removing -all_load from 'Other Linker Flags' fixed the problem.
I have also had this particular error occur when a file that has not been added to the project, is referenced somewhere in the project. The two cases where I have experienced this are where I have deleted/removed files from the project without removing references to them, and when working cooperatively on a project where a teammate added the reference but I have not added the file to my version of the project.
I know the OP has resolved their problem, but I felt this might help someone else who reads this question while looking for help.
I have figured out the solution myself, sorry for posting little delayed. All assistance are much appreciated the but problem arises when I add new CCLayer derived class and checkmark cocos2d 0.99.5 static library which was wrong. Then I re-Ad my class without checking and clean my targets and then build and go. Problem solved now.
I had a project with 2 targets. A target named Component and the second named Sample. Sample was using component as a link library.
Then Component was using a pod named MyPod (installed with cocoapod).
The Podfile was written like this :
def shared_pods
pod 'MyPod'
end
target 'Component' do
shared_pods
end
target 'Sample' do
shared_pods
end
Both targets was referencing the shared pod list. When building Component target, no problem appears, but when building sample i get a duplicate symbol _OBJC_METACLASS_$_ClassName.
I have changed the Podfile to :
def shared_pods
# empty
end
target 'Component' do
pod 'MyPod'
shared_pods
end
target 'Sample' do
shared_pods
end
And that solve the problem.
3 hours spent, hope to save somebody time.
XCode Beta crashed for me while deleting a reference to a class. This caused the problem described in the answer, the fix was different again.
In my Target's Build Phase, under "Compile Sources", the item giving me grief was red. I couldn't remove it with the minus button, but typing "skip" in the compiler flags caused the red class to disappear after reloading the project. I'm assuming you could type anything in there.
It took me two hours to find the solution to my prob, I put it in here for another option to those having this problem, although it is probably not going to be a common one.
None of the Answers worked for me, so what I did was remove the files from the project and choose only Remove References.
Then I added back the same files and it worked.
That fixed my error. Maybe XCode got lost references stored somewhere since the project is multi-collaboration.
Hope that helps someone.
Another possibility for error like this is when there is a class name collision. Either 2 classes with the same name within your project, or class from your project clashing with one defined in some of dependency libraries.
Remove target from right panel and again add target. This will remove any duplicate references.
It may happen if 2 programmer add the same target and commit the project file.
In my case I was using a binary library includes the same class name I was using outside,
So I changed my class name and It's working fine :)
In my case, I had added the libxxxx.a to Link Binary with Libraries section in the subProjects as well as in the mainProject. Hence there were duplicate symbols. Removing from subProjects fixed it.