Having problems importing diff class, in Xcode 10. This doesn't occur in their previews version. Any Suggestion to fix this?
Based on Xcode release notes you have to use include syntax.
The legacy header map that was generated when the Always Search User
Paths (ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by
the new build system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and
migrate to using modern header include syntax. Add any needed header
files that are in the project repository to the Xcode project to
ensure they are available for use in #include (via the project wide
header map). Use quote-style include ("foo.h") for project headers,
and reserve angle-bracket include () for system headers.
For example:
#import <SystemFile/SystermFile.h>
#import "ProjectFile.h"
Related
I'm developing an iOS framework that mixes Objective C and Swift code. Build fails at the #import "Example-Swift.h" line with 'Example-Swift.h' file not found.
The header file does get generated, I can find it at:
DerivedData/Example/Build/Products/Debug-iphonesimulator/Example.framework/Headers/Example-Swift.h
I tried all of the upvoted solutions on Stack Overflow, none worked. The only fix is manually adding the directory to User Header Search Paths in build settings.
I must be doing something wrong though if other people don't have to manually add the header path. Also, when users of this framework include it as a pod, they need to do update the build settings as well, which I really want to avoid.
So, is there a solution to this that's not an ugly hack? I'm using XCode 9.0.1. I wish Xcode / iOS had a normal build system... coming from Linux/Android, I like many things about the iOS ecosystem but the build system is just ridiculous.
I've seen this problem in a mixed Objective-C/Swift framework and my solution was to include the module name as the directory part of the include. In your case it would be
#import "Example/Example-Swift.h"
instead of
#import "Example-Swift.h"
This is actually documented in the Importing Swift into Objective-C subsection of Importing Code from Within the Same Framework Target at https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
I have previously built a Keyboard extension project that has components of both Swift and Objective C. I'd like to built a new Keyboard app based on my previous app, with the simple goal of changing the name, keyboard UI and some keyboard mechanics.
I followed the guidelines here on duplicating and renaming an XCode Project. I even managed to get the project to compile after changing the Bundle IDs (for both the container app and the underlying keyboard). However, because of the name of the Targets have now changed, I am get the error that the following files:
#import "NewNameContainerApp-Swift.h"
#import "NewNameContainerApp-Bridging-Header.h"
cannot be found (these errors persist despite me manually changing OldNameContainerApp-Bridging-Header.h to NewNameContainerApp-Bridging-Header.h. It seems that the project has not regenerated a new set of bridging header and -Swift.h files matching the names of my new target.
My question is - is there a way to force XCode to regenerate a new set of these files? And if not, where do I find OldNameContainerApp-Swift.h so I can manually change it to NewNameContainerApp-Swift.h?
Thanks!
Check in your applications Define-Module in the build section. Update it to your latest project name. To find it easily just search for Defines-Module and see if it needs updating. If it is updated try cleaning your project or deleting your Derived Data
I have found no way to force Xcode to regenerate these files. Removing them just causes builds to fail. The only reliable method is to do a clean build, or removed DerivedData and rebuild (effectively the same solution).
When renaming an Objective-C/Swift mixed app, the following additional changes have to be performed for a successful build.
The Swift to Objective-C header file depends on the module name:
<ModuleName>-Swift.h
So if the Module name changes, you need to change the import in your code. In build settings search for Product Module Name to find the module name that is being used.
The Objective-C to Swift bridging header name depends on the build setting Objective-C Bridging Header. Check the Xcode target build settings and modify to match your new name.
I am playing around with some of the new iOS 7 features and working with some of the Image Effects as discussed in the WWDC video "Implementing Engaging UI on iOS". For producing a blur effect within the source code for the session, UIImage was extended via a category which imports UIKit like so:
#import UIKit;
I think I saw something about this in another session video but I'm having trouble finding it. I'm looking for any background information on when to use this. Can it only be used with Apple frameworks? Are the benefits of using this compiler directive enough that I should go back and update old code?
It's a new feature called Modules or "semantic import". There's more info in the WWDC 2013 videos for Session 205 and 404. It's kind of a better implementation of the pre-compiled headers. You can use modules with any of the system frameworks in iOS 7 and Mavericks. Modules are a packaging together of the framework executable and its headers and are touted as being safer and more efficient than #import.
One of the big advantages of using #import is that you don't need to add the framework in the project settings, it's done automatically. That means that you can skip the step where you click the plus button and search for the framework (golden toolbox), then move it to the "Frameworks" group. It will save many developers from the cryptic "Linker error" messages.
You don't actually need to use the #import keyword. If you opt-in to using modules, all #import and #include directives are mapped to use #import automatically. That means that you don't have to change your source code (or the source code of libraries that you download from elsewhere). Supposedly using modules improves the build performance too, especially if you haven't been using PCHs well or if your project has many small source files.
Modules are pre-built for most Apple frameworks (UIKit, MapKit, GameKit, etc). You can use them with frameworks you create yourself: they are created automatically if you create a Swift framework in Xcode, and you can manually create a ".modulemap" file yourself for any Apple or 3rd-party library.
You can use code-completion to see the list of available frameworks:
Modules are enabled by default in new projects in Xcode 5. To enable them in an older project, go into your project build settings, search for "Modules" and set "Enable Modules" to "YES". The "Link Frameworks" should be "YES" too:
You have to be using Xcode 5 and the iOS 7 or Mavericks SDK, but you can still release for older OSs (say iOS 4.3 or whatever). Modules don't change how your code is built or any of the source code.
From the WWDC slides:
Imports complete semantic description of a framework
Doesn't need to parse the headers
Better way to import a framework’s interface
Loads binary representation
More flexible than precompiled headers
Immune to effects of local macro definitions (e.g. #define readonly 0x01)
Enabled for new projects by default
To explicitly use modules:
Replace #import <Cocoa/Cocoa.h> with #import Cocoa;
You can also import just one header with this notation:
#import iAd.ADBannerView;
The submodules autocomplete for you in Xcode.
Nice answer you can find in book Learning Cocoa with Objective-C (ISBN: 978-1-491-90139-7)
Modules are a new means of including and linking files and libraries into your projects. To understand how modules work and what benefits they have, it is important to look back into the history of Objective-C and the #import statement
Whenever you want to include a file for use, you will generally have some code that looks like this:
#import "someFile.h"
Or in the case of frameworks:
#import <SomeLibrary/SomeFile.h>
Because Objective-C is a superset of the C programming language, the #import state‐ ment is a minor refinement upon C’s #include statement. The #include statement is very simple; it copies everything it finds in the included file into your code during compilation. This can sometimes cause significant problems. For example, imagine you have two header files: SomeFileA.h and SomeFileB.h; SomeFileA.h includes SomeFileB.h, and SomeFileB.h includes SomeFileA.h. This creates a loop, and can confuse the coimpiler. To deal with this, C programmers have to write guards against this type of event from occurring.
When using #import, you don’t need to worry about this issue or write header guards to avoid it. However, #import is still just a glorified copy-and-paste action, causing slow compilation time among a host of other smaller but still very dangerous issues (such as an included file overriding something you have declared elsewhere in your own code.)
Modules are an attempt to get around this. They are no longer a copy-and-paste into source code, but a serialised representation of the included files that can be imported into your source code only when and where they’re needed. By using modules, code will generally compile faster, and be safer than using either #include or #import.
Returning to the previous example of importing a framework:
#import <SomeLibrary/SomeFile.h>
To import this library as a module, the code would be changed to:
#import SomeLibrary;
This has the added bonus of Xcode linking the SomeLibrary framework into the project automatically. Modules also allow you to only include the components you really need into your project. For example, if you want to use the AwesomeObject component in the AwesomeLibrary framework, normally you would have to import everything just to use the one piece. However, using modules, you can just import the specific object you want to use:
#import AwesomeLibrary.AwesomeObject;
For all new projects made in Xcode 5, modules are enabled by default. If you want to use modules in older projects (and you really should) they will have to be enabled in the project’s build settings. Once you do that, you can use both #import and #import statements in your code together without any concern.
#import Module(ObjC) or Semantic import
instead of usual module using
//as example
#include <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
History:
[#include -> #import] -> [Precompiled Headers .pch] -> #import Module(ObjC); -> [import Module(Swift)]
It is a part of LLVM Modules
#import <module_name>; declaration says to compiler to load(instead of compile) a precompiled binary of module which decrease a building time. Previously compiler compiled dependency every time when runt into it but now it should be compiled beforehand and just loaded
//previously
run into dependency -> compile dependency
run into dependency -> compile dependency
//#import
compile dependency
run into dependency -> load compiled binary
run into dependency -> load compiled binary
[Modulemap] - bridge between module and headers
Xcode
Enable Modules(C and Objective-C)(CLANG_ENABLE_MODULES) - CLANG #include, #import directives are automatically converted to #import that brings all advantages. Modulemap allows to do it seamless because contains a map between headers and sub/modules
Pass -fmodules
#include, #import -> #import
Link Frameworks Automatically(CLANG_MODULES_AUTOLINK) - enables system modules auto linking. Requires activated CLANG_ENABLE_MODULES. Auto-linking allows to pass -framework <framework_name> based on #import, #import(Objective-C), import(Swift)
If NO - passes -fno-autolink flag
CLANG_ENABLE_MODULES == NO and CLANG_MODULES_AUTOLINK == NO
If you want to handle system(#import <UIKit/UIKit.h>) linking manually(instead of auto-linking) you have two variants:
Add dependency into General -> Frameworks and Libraries or Frameworks, Libraries, and Embedded Content
Build Settings -> Other Linker Flags(OTHER_LDFLAGS) -> -framework <module_name>
Next error will be thrown if:
Undefined symbol: _OBJC_CLASS_$_UIView
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_UIView", referenced from:
objc-class-ref in ClassB.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
CLANG_ENABLE_MODULES is disabled
CLANG_MODULES_AUTOLINK is disabled and no manual linking
Reverse engineering
otool -l <binary>
//-l print the load commands
//find LC_LINKER_OPTION
//cmd LC_LINKER_OPTION
It currently only works for the built in system frameworks. If you use #import like apple still do importing the UIKit framework in the app delegate it is replaced (if modules is on and its recognised as a system framework) and the compiler will remap it to be a module import and not an import of the header files anyway.
So leaving the #import will be just the same as its converted to a module import where possible anyway
It seems that since XCode 7.x a lot of warnings are coming out when enabling clang module with CLANG_ENABLE_MODULES
Take a look at Lots of warnings when building with Xcode 7 with 3rd party libraries
There is a few benefits of using modules. You can use it only with Apple's framework unless module map is created. #import is a bit similar to pre-compiling headers files when added to .pch file which is a way to tune app the compilation process. Additionally you do not have to add libraries in the old way, using #import is much faster and efficient in fact. If you still look for a nice reference I will highly recommend you reading this article.
I often see open source code importing third-party libraries in Xcode / Objective-C implementation files like this:
#import <ThirdPartyLibrary/utilities.h>
but when I drag & drop the file structure and files of such a library in my project, all these imports are corrupted and Xcode does not know where the files are.
I end up hand-modifying every import to look like:
#import "utilities.h"
And include appears it is relative to the current physical folder on the file system. When a library split its files in folders on file system and I drag-drop it in Xcode, Xcode creates groups for the folders. But for import, I have to specify the folder name. Problem is when I am in a folder, for example:
http/httpTools.h
Then when httpTools.h wants to import utilities.h from the root, I have to change
#import <ThirdPartyLibrary/utilities.h>
to
#import "../utilities.h"
which is a chore. After doing this for 5 hours I thought damn, there must be a better way. Can someone explain what is the secret to teaching Xcode a new framework location that can be imported with angle brackets? The framework btw is source code. Not compiled. Just the naked code.
Specify the include path using the compiler flag -I, or the Xcode build settings alias HEADER_SEARCH_PATHS. Of course, you can use build variables when doing so.
Just stumbled upon the same issue, there are two types of search paths in Xcode:
Header Search Paths
User Header Search Paths
If you add your own include folders into Header Search Paths, you can use angled brackets.
I'm looking to create a precompiled header file, to avoid having to include the same debug and tracking libraries in every header in the project.
I've created a file called -Prefix.pch:
#ifdef __OBJC__
#import "Blah.h"
#import "Blarg.h"
#endif
and added it to the project. Is there anything more I'm supposed to do, or should things just work now (assuming I do a project clean and recompile)?
Set the target's build settings as follows:
GCC_PRECOMPILE_PREFIX_HEADER=YES
GCC_PREFIX_HEADER="Prefix.pch"
Note that you can plop these keys in the Build Settings search field, if you prefer to use Xcode's UI for your build settings.
I got this error in my flutter app when using the library flutter_inappwebview and tried to set deployment version of ios in Runner > General to 12.0.
I set it back to 11.4 and it built with no problems.