Modulemap exposes C header files for external binaries. It is a bridge between module and headers. Modulemap helps to convert #include, #import -> @import because it has a mapping between module name and headers inside. Also modulemap helps to create standalone additional modules and submodules.
Make sure the header files are publicly available as part of the framework's public headers.
Goto Framework -> Target -> Build Phases and drag to move the relevant header files from Project to Public. Hope that helps!
Try going Build Settings under "Target" and set "Allow Non-modular Includes in Framework Modules" to YES.
The real answer is that the location of the imports needs to be changed by the library owner. Those files ifaddrs.h, arpa/inet.h, sys/types.h are getting imported in a .h file in a framework, which Xcode doesn't like. The library maintainer should move them to a .m file. See for example this issue on GitHub, where AFNetworking fixed the same problem: https://github.com/AFNetworking/AFNetworking/issues/2205
You can set Allow Non-modular includes in Framework Modules in Build Settings for the affected target to YES. This is the build setting you need to edit:
NOTE: You should use this feature to uncover the underlying error, which I have found to be frequently caused by duplication of angle-bracketed global includes in files with some dependent relationship, i.e.:
#import <Foo/Bar.h> // referred to in two or more dependent files
If setting Allow Non-modular includes in Frame Modules to YES results in a set of "X is an ambiguous reference" errors or something of the sort, you should be able to track down the offending duplicate(s) and eliminate them. After you've cleaned up your code, set Allow Non-modular includes in Frame Modules back to NO.
I had the same problem and solve it by just making header file public.
If you are working on multiple modules in your project. Then your header file needs to be public to be used in other parts of projects. What you need is to select that header file, and in project Utilities view. Change the file from Project/Private to Public. See image below:
"Include of non-modular header inside framework module"
When you get this error the solution in some circumstances can be to simply to mark the file you're trying to import as "public" in the file inspector "Target Membership". The default is "Project", and when set this way it can cause this error. That was the case with me when trying to import Google Analytic's headers into a framework, for example.
Actually an easier way to fix this is to move the #import
statement to the top of the .m
file instead (instead of having it in your .h
header file). This way it won't complain that it's including a non-modular header file. I had this problem where Allow non-module includes
set to YES
did NOT work for me, so by moving it to the implementation file, it stopped complaining. This is in fact the preferred way of importing and including header files anyway. Once you've done this, setting this back to NO
should work.
Ideally we should try and aim to have Allow non-module includes
set to NO
. Setting this to YES
in most cases means you're doing something wrong. The setting translates to "Allow importing random header files on disk that aren't otherwise part of the module". This applies to a very few use cases in practice, and so this setting should always be NO
(i.e. the default value).
Allow Non-modular Includes in Framework Modules
only work in objc code. not work in swift.
After a period of research, I found that swift can pass warning parameter to clang, so set OTHER_SWIFT_FLAGS
to -Xcc -Wno-error=non-modular-include-in-framework-module
inhibit swift import error.
just for someone who have same problem
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With