I have an app target which includes a mix of Objective-C and Swift code. The Swift code uses Objective-C code and vice versa.
The app target is compiling fine, but when I try and compile my test target, it can’t find the “Objective-C Generated Interface Header”. Although the app target compiles fine, when it comes to compiling the app source code in the test target, the #import “MyApp-Swift.h” file results in a “file not found” error from the compiler.
If I check in the DerivedData folder, I can see the MyApp-Swift.h file inside the DerivedSources folder for the app MyApp.build folder, but not for Tests.build (which has no DerivedSources folder).
Does anyone know how to resolve this issue please?
Ensure that the app source files are only included in the app target and not in the test target as well.
Although it used to be necessary to include the app source in both the app and test targets, this is no longer the case.
Related
This one is not easy to explain, but is also very annoying.
I'm working on a Cocoapods framework (in development mode) with objc and swift sources. Let's call it the "SuperCompoment" framework
Xcode auto generates the SuperComponent-Swift.h file, to make Objc classes visible from Swift ones.
Some Objc classes also includes Swift classes.
At compile time, in the SuperComponent-Swift.h, Xcode adds the line
#import <SuperComponent/SuperComponent.h>
... and fails to compile with the message: SuperComponent/SuperComponent.h file not found
Xcode tries to include the framework inside the framework itself!
If I manually edit the auto-generated file by commenting the #import, the project compiles perfectly. But Xcode auto-generates the file after each clean and before archiving the project!
Any clue?
I don't know why Xcode automaticaly adds the #import <SuperComponent/SuperComponent.h> line (since it do work without it), but if i'm kind with him by adding an empty SuperComponent.h file at the root of my framework, it compiles gracefully.
I had a perfectly working ObjC project integrated with Apple WatchKit App with Multiple Targets. Only one of the Targets is linked with the WatchKit App.
I am moving my classes to swift and hence there are ModuleName-Swift.h files being used in my code.
Followed steps given in ModuleName-Swift.h file not found in xcode8 and I have ensured to add the “$(PROJECT_NAME)-Swift.h” under Projects > Build Settings > Objective-C Generated Interface header name.
But when I go to the build settings - it shows as Objective-C generated interface header name for the project target and Swift_ObjC_Interface_header_name for WatchKitApp Target
Error thrown by compiler : ProjectName-Swift.h file Not found
Is this causing the error? Not sure what I am Missing.
This is how I've linked the -swift.h files in Other targets
The issue was:
There were Unit test cases that were failing, disrupting further Compiling of the Project
Quick Fix:
The ObjectiveC Classes had Unit test cases associated with it.
Some of the Unit tests were failing due to changes to the main code base.
I had to uncheck the the following under Edit Schemes > Build so that they don't Build while running the WatchKit App.
I agree I will have to update the test cases to work with the Updated app, But the issue of Watch App not working is Fixed! :)
I'm working to create an iOS static library that I wish to sell. I've walked through the steps for the initial builds and have generated the .a/.h output.
When I include these files in a separate project, I don't see any way to browse the contents on the .a file.
HOWEVER, when a line of code in my library crashes the app (like I said, it's still in development), the debugger shows the entire class (.m) file to me. What's up with this?
I don't really understand what all goes into static libraries, and I'm not sure I compiled that version for both simulator and device. Could that have something to do with it? If so, could someone explain why?
Thanks!!!
Don't worry, your source code is not included in the archive (.a) file.
Xcode is smart enough to find the source code file on your computer, based on the debugging information embedded in the file. If you build the library using the "Release" configuration (or otherwise modify the build settings so that debugging symbols are stripped) and don't have the source anywhere on the machine, a developer will have to resort to their knowledge of x86 or ARM assembly to figure out how your code works.
By the way:
Since a lot of Objective-C is handled at runtime, a lot of class names and selector names will be visible in your library. That's just how it works. You could try to obfuscate it, but I think your time is better spent writing more useful code to sell.
If you want to give people a static library for iOS development, you'll want to build versions for the iOS Simulator (x86) and the iOS Device (arm) and then use lipo to combine them into a single fat static library. Search around for "lipo xcode fat static library" for different ways to do this. Some solutions are more convoluted than others.
I had the same issue. #benzado is right about what he has mentioned. But I had to strip debugging symbols to solve the issue. To do so, I had to change Build Settings of project library before build as mentioned below.
Select your Target and go to Build Settings. Set
' Strip Debug Symbols During Copy ' to YES
' Debug Information Format ' to 'DWARF with dSYM File'
' Generate Debug Symbols ' to 'NO'
' Symbols Hidden by Default ' to 'YES'
To see what are these for, refer Apple Build Setting Reference
And build the library using the "Release" configuration. This worked for me.
If you have a project for static library with all .m files on your computer then every copy of this library (.a file) will be symbolicated with its .m file while debugging in xCode.
xCode doesn't search for appropriate .m file through all your disk. It knows the place of original project. So if you distribute only library it fully hides your initial code.
To make sure you can copy your library in some new project then clear .m file in library project.
From this moment any attempt to debug methods of library will give empty file on screen.
I have a project with two targets, one is a Cocoa Static Library, the other is the accompanying test project. Despite building the main project in different ways over and over again, I cannot find the .a file that I expect it to produce.
In fact, I cannot find the build folder associated with the project. I need to link to the library in an app, but cannot do so if I can't find the file to link to.
These properties are correctly set:
(Build Products Path) SYMROOT = build
(Intermediate Build Files Path) OBJROOT = $(SYMROOT)
All tests pass (which means the code MUST be building right?)
Breaking the code causes the build to break - again suggesting that it is building.
Also, the "Products > libproject.a" file is red in the xcode project navigation
I also checked the DerivedData directory, but all the seems to get created is the objects fot the OCunit stuff. Still no .a file against which I can link.
Where is my .a file?
Any help would be much appreciated.
It's probably in ~/Library/Developer/Xcode/DerivedData/ somewhere.
I downloaded Andy Potion's "PFLetsMove" framework here and added the Xcode Project to my application's project. I then dragged the framework from that to the Link Binary with Libraries and Copy Files build phases.
Now, if I compile the application with a call to PFMoveToApplicationsFolderIfNecessary() it works fine, so the framework is definitely there. But if I put the line #import "PFLetsMove/PFMoveApplication.h" in the app delegate, I get the following error: 'PFLetsMove/PFMoveApplication.h' file not found.
I've checked the compiled PFLetsMove.framework in the build folder, and PFMoveApplication.h is there. I did the exact same thing with the AquaticPrime framework (import the header) and it works fine. Where am I going wrong here, or is there potentially an issue with how the framework is built?
If you use a framework, you put the file name in angle brackets (i.e. <FrameworkName/FileName.h>), if it's a local file, you use quotes (i.e. "FileName.h"). Note that even if the source file is in a group or subfolder, it is not referenced as such.