For starters, this only became an issue after upgrading to Xcode 13. I have an app that was written in Objective-C and am utilizing some files written in Swift. In order to access classes that were created in the app in Objective-C, I do have a bridging-header named TargetName-Bridging-Header.h, where all of the classes in question are being imported like so:
#import "ClassName.h"
In the target Build Settings, Objective-C Bridging Header's value is set to the path of the bridging-header file (ProjectName/TargetName-BridgingHeader.h), and the app seems to have no problem finding it. Precompile Bridging Header is set to Yes. Install Objective-C Compatibility Header is set to Yes. Furthermore, the app builds and runs and seems to have no problem accessing those Objective-C built classes, yet the compiler continues to throw errors stating that it cannot find those classes. I've tried deleting derived data and cleaning. What am I missing? Is this perhaps a new Xcode bug that anyone else has experienced?
The exact error is "Swift Compiler Error: Cannot find 'ClassName.h' in scope"
Had the same problem, I removed the specific import statement from the bridging header, put it back and saved...next compilation went smooth without any errors. weird bug...but avoidable..
Related
I cannot get my swift files imported into my Obj-C project. I know, there’s a lot already on this topic on stack overflow, and I’ve tried all answers in this thread on importing Swift code to Objective-C, but I've still got the same error in spite of what I've tried for my project called Plantasia:
When at the top of the script of the .m file of a pre-existing project I do
import "Plantasia-Swift.h"
I get file not found error.
What I've tried:
I've set for both project and example
"Defines Module" : YES
"Always Embed Swift Standard Libraries" : YES
"Install Objective-C Compatibility Header" : YES
Changed the Project Module Name to Plantasia
I’ve cleaned my build folder and tried a bunch of unlikely solutions like #import "Plantasia/Plantasia-Swift.h" , which don't work either.
I’ve tried prepending #objc to class declaration in the .swift file.
I’ve tried manually adding another bridging header, and specifying the "Swift Compiler – Code Generation" to my header.
I've tested starting from a blank Objective-C project, by creating a Swift file, and referenced it successfully within .m file. This shows that it's at least working normally for me in a clean project
I've been trying for hours, and I think there must be one incorrect setting somewhere that I'm unaware of. I've tried basically most of what I could find on the forums. Any additional ideas of things I should still check? Or is there a way of manually creating this "Plantasia-Swift.h" header file?
I downloaded this Xcode project and I want to use my Swift files in the Objective-C files but the 'OpenShop-Swift.h' file not found error refuses to go away.
I have tried what seems like every solution on Stack Overflow, including from here and here. Most other solutions were duplicates of the common:
In build settings, set defines module to yes and product module name for the target to your project name and make sure objective-c generated interface header name is correct.
This top solution seemed promising but I am having trouble understanding what he was saying.
If you decide to give it a whirl, just know that the project lacks a working backend and won't compile properly if you get past the file not found error. But, if you add to one of the .m files you should be able to get the error before the project finishes compiling.
Technically, this is not a duplicate since all the other solutions have failed.
I have found the solution thanks to #skladek. I created a swift file and allowed Xcode to create a bridging header file for me when it asked, and the error went away.
I thought the bridging header file (OpenShop-Bridging-Header.h) was to allow the importation of Obj-C code to Swift files and not vice-versa. Thus far everything I have read on the internet has corroborated this, so it's not clear to me why this solution works. Thanks to #skladek once again.
I have an iOS project written with Objective-C. I created an Swift class in the project, the bridging header file for accessing objective-c in Swift is generated successfully, and it works fine.
My problem is the other way around. I want to import Swift class in objective-c code.
In xcode, target -> Build Settings--> Swift Compiler section, I see Objective-C Generated Interface Header Name field with value myModule-Swift.h , but when I import this header in my objective-c class:
#import "myModule-Swift.h"
I get compiler error:
myModule-Swift.h file not found
and in project, I cannot find this file either. How can I solve this problem?
My xcode version is 6.4
Updated May 2018 Xcode 9.3
Build Settings->Objective-C Generated Interface Header Nameand set the value to YourModule-Swift.h (this is usually already set, this is the filename you need to import on .m file #import "YourModule-Swift.h"
(Example, Project named CData)
Same as Step 1, Go to Build Settings and search for "Defines Module", set both values to YES
Create a class that extends NSObject on .swift file
Build the project again
Import YourModule-Swift.h file on .m file (Please notice it's case sensitive, Mymodule !== MyModule)
In case anybody is wondering why after spending hours on this issue it is still unresolved, you might be in a situation similar to mine, where I was actually developing a framework, rather than an app.
In such case, the format of the import statement for Objective-C Generated Interface Header is as follows:
#import <ModuleName/ModuleName-Swift.h>
OMG.. the actual import statement was not "class-Swift.h" but rather "projectname-Swift.h"
You can find the name of the file if you look under build settings->Swift Compiler Code Generation -> Objective-C Generated Interface Header Name
The file was not generated when I dragged in Swift source into the GUI. Only when I right-clicked->Add file to "project". It then asked to generate the header files.
My addition to Daniel Kroms answer:
Never add -Swift.h Header to header. Even if it seems to work. Add the Import to .m file only!
In case you use in your header swift classes, make a forward declaration with #class swiftclassname before your #interface
Then you will see your real errors in your code.
For me, the problem was that I had bitcode on. When I clicked on the "Update to recommended project settings", it changed a few settings which probably the culprit. I turned "Enabled Bitcode" to "No" in the Build Settings and it is fixed now.
I was stacked this for a quite a while. In my case, my target name is something like "my-app" using dash as a part of target name. I tried to #import "my-app-Swift.h", but Xcode kept giving me errors.
I dug under 'DerivedData' folder and I found "my_app-Swift.h". So if you are using some interesting characters for the target name. You may try replace those with underscore _.
I ran into the same issue yesterday and worked for hours to fix it with no avail. Others may have been in the same boat as I. I did all of the steps described above, but nothing worked.
The cause of mine breaking was because of project name artifacts all over my project (from previously changing its name improperly).
If all of the above steps fail, I would suggest doing like I did and renaming your project so that Xcode can reset somethings... That solved the problem for me.
Doing so worked like a charm!
In my case, I have forgotten to check a swift framework to the target/classes that I was using it, really specifically case but it may help someone in the future.
For me the solution was to create a new target. For an unknown reason, the target that I had didn't have that "Swift Compiler - General" settings and thus no to "Objective-C Generated Interface Header Name" field. Having that field specified in the project was not enough.
This is not an exact answer but more of a workaround, but can save you time in some difficult cases. If you, as suggested by some of the the previous answers, can actually find the swift header buried inside the derived data folder, you are allowed to import it using the full path. This is not specific to the swift header, instead it can be applied to any header. Hope you can find this answer useful.
This answer solves my problem, but what's confusing to me is that when I convert bitcode to YES, then clean Xcode DerivedData, bulid again,also Bulid succeeds
I import the Facebook AsyncDisplayKit framework into my app using the swift bridging header, like so:
#import <AsyncDisplayKit/AsyncDisplayKit.h>
It's always worked fine for building and running my app, but when I go to archive, it gives me an error:
import 'file not found'
Why might this not be recognized, upon archiving?
I always meet this kind of problem. I think you can try to check your file&folder hierarchy.
Such as you have a root folder named Project, as is often the case, there is another Project in your previous Project, the root folder.
And Checking the Objective-C Bridging Header in the Build Setting. Sometime error can occurred for Project/Project/Bridging-Header.h. And the error can be corrected by changing the definition as Project/Bridging-Header.h.
If the location of Bridging-Header.h is not matching with the definition in the Build Setting, the error like import file not found will occur.
I just tell your my solution for Bridging issue I already met, I hope it can help you.
I'm using AddThis to add sharing options in my iOS app.
I have imported the classes and added the -fno-objc-arc flag to all the imported classes since they don't use ARC.
However, when I try to run the app I get a slew of Parse Issues such as:
Expected identifier or '('
Unknown type name 'NSString'
Unknown type name 'Protocol'
...
These errors occur in NSObjCRuntime, NSZone, and NSObject. I have the requisite frameworks included as well. Any ideas?
Including this image if it helps:
I had the same issue on my project when I was trying to mix C code (.h and .c) with Objective-C code. Found the reason of the issue:
Check your .pch file to make sure every Objective-C framework #import (such as #import <UIKit/UIKit.h>) is enclosed in:
#ifdef __OBJC__
#endif
If they're outside of this conditional scope, the compiler will try to import Objective-C frameworks into C source code.
I just changed the filename of Base64Transcoder.c to Base64Transcoder.m, and now the project compiles. I have no idea why this fixes the problem, but it works.
I had the same issue, using C and C++ code with objective C, and i doesnt have a .pch
The easiest solution was to go into your build settings -> Custom Compiler Flags and set the "Other C Flags" to "-x objective-c" and set the "Other C++ Flags" to "-x objective-c++"
this will do the trick with xCode 7.2
I have had the same problem when my project contained .cpp files.
If .cpp file doesn't contain ObjectiveC frameworks(e.g. ) it has to 'Default-C++ Source' type
,
but if .cpp file has ObjectiveC frameworks - it must be as 'Objective-C++ Source'
TLDR: if your PCH file is OK, look through your CPP file headers to see if you've accidentally included any headers for Objective C objects.
The Details:
I got this because I had accidentally included an Objective-C class header in a C++ class header, indirectly. The structure was this:
Compass.h defined a pure Objective C class.
ActionTracker.h defined a C++ class that understood Objective C constructs (via ActionTracker.mm).
HelloWorld.h defined a purely C++ class.
In my original setup, HelloWorld.h included ActionTracker.h, but this was OK as ActionTracker.h didn't yet contain Compass.h. Later, I changed my code and included Compass.h in ActionTracker.h, which then pulled it into HelloWorld.h and I got these errors.
I had this same problem when I tried to move the info.plist file from one directory to another.
This somehow triggered XCode to edit the build phases for that target and significantly increased the amount of "Compile Sources" and "Copy Bundle Resources".
Luckily my project has multiple targets that I use for testing, (i.e. App Demo, App Dev, App Local, App 1.1, App 1.2 etc)
So I just duplicated one of the unaffected targets and renamed it (also renamed the bundle identifier and the build scheme) and this obviously fixed the problem for me since it's not the whole project that was affected but only that specific target.
If you want to try my solution, try to create a new target from scratch, or duplicate and rename any of your un-affected targets.