I'm successfully calling my Swift classes from Objective C (for target 'MyApp') via the import statement:
#import "MyApp-Swift.h"
I've now created a new target called "MyAppLite"
When I compile the new target, I get errors because "MyApp-Swift.h" is required by the code, but the compiler is creating "MyAppLite-Swift.h"
So, I need to create a conditional Swift/ObjC header #import for the target I'm compiling against.
How can this be done, or is there a better way?
It is also possible to set the Product Module Name setting in Build Settings to be the same across your modules (I set it to $(PROJECT_NAME)), so that the <project>-Swift.h file that is generated has the same name across all modules. This eliminates the need for adding/checking preprocessor macros.
The best way I've found to address this issue is in your Xcode shared project settings. You can search for the following setting:
Objective-C Generated Interface Header Name*
If you set that value to a common header name, such as "MyProject-Swift.h", it will be applied to each of your targets and you can safely use the import declaration in any of your Objective-C files. This allows you to continue using unique product module names for each target, if needed.
I've tested this in Xcode Version 6.4 (6E35b).
*Note: This will appear under your Swift compiler settings, which are only visible if you have Swift source files added to your project. Additionally, if a target doesn't have any Swift source associated with it, the Swift compiler options will not be visible for that target's build settings.
Good luck!
Previous answers have some problems if you decide to rename your targets or project, or use SWIFT_MODULE_NAME as intended.
The most universal solution is to change SWIFT_OBJC_INTERFACE_HEADER_NAME (“Objective-C Generated Interface Header Name”) under Project's, not Targets, Build Settings, to:
$(PROJECT_NAME)-Swift.h — one per project;
$(SWIFT_MODULE_NAME)-Swift.h — one per module (default value).
Well, the only way I can fix is to...
#ifdef IS_LITE
#import "MyApp_Lite-Swift.h"
#else
#import "MyApp-Swift.h"
#endif
Note that if there's any 'illegal' chars in my Product Module Name, they need to be replaced with underscores.
Hope that helps!
I put the appropriate #import <project>-Swift.h statement in a prefix header file (<project>-Prefix.pch) defined/added for each build (target/scheme).
pickture will tell you all
second targets name xxx and xxx-ih
select first target tap build setting -> find Objective-C Bridging Header set xxx-bridging-Header.h and Objective-C Generated Interface Header Name set xxx-Swift.h
select second target and same step 2
The only working way is the following :
1- from first target (which has a working bridging) Build Setting select Objective C Bridging Header
2- Copy Objective C Bridging Header
3- open the other target Build Setting
4- Paste it
5- change the header file to your new header file (i.e target B.h)
(now you have this option for two target)
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.
when i compile my project, i have this error :
ld: duplicate symbol _OBJC_CLASS_$_DNCloseButton in /Users/.../Library/Developer/Xcode/DerivedData/...Objects-normal/i386/DNCloseButton-7045D069F03DAA13.o for architecture i386
Command /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang++ failed with exit code 1
I know that the problem is about the class DNCloseButton but i don't how to solve it ? thanks for your answers.
Ensure you've only declared the interface once, in a header file (.h), and imported that header file with #import and not #include.
Sometimes XCode cocks up a little bit and links the same file twice at the linker stage. To fi this:
Remove the file from your project (select the 'remove references' option) and then add it again.
Clean with shift-cmd-k
Build
Hope this helps!
This will happen if a source file is include twice in your Compile Sources Build Phase.
To check this in Xcode 4:
Select your Project from the file list.
Select your target from the left column.
Click on the Build Phases tab on the top bar.
In the search field, type in the name of the class that is causing the linker error. In the case of the question above, it is DNCloseButton (ignore the preceding _).
If the source file for the class appears twice in the Compile Sources list, delete one of the entries.
You might also get this error if you by accident #import the .m file instead of the .h file.
This may happen in the following cases.
You have put the same class implementation into two different files;
You actually have just one implementation of this class, however you are also linking in your project a framework or library containing a class whose name is exactly the same of yours.
Try finding in the whole project your class and make sure only one copy is available within your project.
How should I respond to this warning?
warning: duplicate protocol definition of '...' is ignored
My protocol declaration is in its own .h file, and it is #import'ed in a few other files in my project.
Well, just in case, here's the entire header file with the protocol declaration:
#import <Foundation/Foundation.h>
#class Wrapper;
#protocol WrapperDelegate
#required
- (void)wrapper:(Wrapper *)wrapper didRetrieveData:(NSData *)data;
#optional
- (void)wrapperHasBadCredentials:(Wrapper *)wrapper;
- (void)wrapper:(Wrapper *)wrapper didCreateResourceAtURL:(NSString *)url;
- (void)wrapper:(Wrapper *)wrapper didFailWithError:(NSError *)error;
- (void)wrapper:(Wrapper *)wrapper didReceiveStatusCode:(int)statusCode;
#end
Thanks for any advice.
Check to make sure you don't have the header file added in your project twice, or two different files that both implement the protocol. This is what caused the warning to appear for me.
Yes I had the same problem. I was unable to find the duplicate header file in Xcode project.
But when i went through the finder from the Xcode i found the 2 header file of the protocol in the project.
Deleting one solved the problem.
Thanks.
Just to supplement the existing answers here with the specific problem I encountered.
Basically, the compiler isn't lying. It is finding more than one definition of a class, protocol, enum, define, or whatever exists in the offending header files.
The fault could be a combination of your header files and the header search path.
At first, the issues seem puzzling as we know that the statement #import will only import files that have not already been implemented. Therefore, unlike #include, this problem shouldn't happen, right?
#import does work. However, if your headers have been set up incorrectly then although it may encounter a file with the same name, e.g. MyLibrary.h, if that file exists in two different places both of which are in the header search path then Xcode will perceive those as two different files.
In my case, I had a static library build phase which copied public headers.
The dependent products searched the folder above - defined in Build Settings as include/$(TARGET_NAME) - and the source folder of my project.
That meant two different folders - both in the header search path - that contained the file MyLibrary.h. Everything in that file would cause a duplicate or redefinition compiler warning or linker error.
TLDR: the same file may be in two different folders and both are in your header search path. Check your paths, and if you've incorporated a static library into the project or workspace, also check where the public headers are copied to as part of your investigation.
Please make sure you have used
#import
rather than
#include
Find the difference here.
Just as background, there are no compile-time errors or warnings in the subject project "Project".
There are numerous occurrences of using the same instance variable name in two (or more classes). In the following, I'll use the variable name "index" as an example. It appears as an instance variable in class1 and class2. The variable has different but similar meanings in both classes, hence the use of the common term.
I define index in the header file for both class1 and class2, for example:
#interface class1 : NSObject
{
int index;
}
...
Repeat for class2.
When I build the project, Xcode reports:
Duplicate symbol _index in /Project/build/Project.build/Debug-iphonesimulator/Project.build/Objects-normal/i386/class1.o and /Project/build/Project.build/Debug-iphonesimulator/Project.build/Objects-normal/i386/class2.o
Changing the occurrences of "index" to "indexnotverycommon", reports the same error with the new name.
Changing the occurrences to "index1" and "index2" respectively gets rid of the error. Xcode then reports the next duplicate it finds during linking, and so on, and so on.
I can continue the renaming process although I'd rather not, as I'm concerned that there is a more pathological underlying issue.
Any advice or question is appreciated.
index is a also a C function and thus a very unfortunate name in Objective-C.
This article describes why it's not a good idea to use index as a name.
I'm not sure why you get duplicate symbols though.
I figured it out using the Xcode find-in-project feature. Thanks for the advice about index.
don't #include or #import .m files. Just add those .m files into the Target | Build Phases. Don't add .h files into build phases, but #import .h files wherever you need those functions.
The compiler knows that it's just a header file "for information only" and that the bodies of the functions will be available when it will compile the .m files and put them all into 1 executable
The header file contains only forward declarations. Compiler knows that the body is either defined in another file or is in a lib linked to the project
The tip to check for an #import "Xxx.m" instead of the correct .h worked.
A quick workspace wide search for "Xxx.m" spotted the error in the include which was causing the link error.