objective-c 'fbsdkcorekit - Swift compiler error: “non-modular header inside framework module”




10 Answers

Is your header public?

Select the header file in the project explorer. Then in the section on the right in xcode, you'll notice there is a dropdown next to the target. Change that from "project" to "public". This worked for me.

'rxlibrary' xcode

Now I would like to migrate my ObjC framework to Swift and I got the following error:

include of non-modular header inside framework module 'SOGraphDB'

The references is to a header file which just define a protocol and I use this header file in some classes to use this protocol.

Is seems related to the module feature but it is at the moment not quite clear how to fix, do you know a solution?

UPDATE:

This is a Swift compiler error.

UPDATE 2:

A quick fix (but not solving the root cause) is to set the following setting to yes: CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YES




Here's how to automatically apply the quick fix so you don't have to change Pods.xcodeproj manually after each pod install.

Add this snippet to the end of your Podfile:

post_install do |installer|
  installer.pods_project.build_configuration_list.build_configurations.each do |configuration|
    configuration.build_settings['CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'] = 'YES'
  end
end



I think I got around this. I have some model code that uses sqlite3 in a framework. In my case, the culprit was <sqlite3.h>.

The problem was that in my Module/Module.h header, I imported a public header that imported <sqlite3.h>. The solution was to hide all the sqlite3_xxx types and make sure they were not visible in any public .h. All direct references to sqlite3 were made private or project visibility. For example, I had a public singleton that had some sqlite3_stmt pointers hanging off it. I moved those to a separate class that is now only a forward declaration in that public header. Now I can build.

Incidentally, the CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES setting didn't work. I tried setting it both in the framework and the dependent project. This workaround was necessary, though I'm not sure why.




This answer is out-dated.

When importing frameworks, you must import all header files that share dependencies with the root header. The easiest way to ensure this always works is to import all headers in the framework's "Headers" folder into your public headers path.

The Swift compiler uses this information to generate a map of non-mangled symbols along with their associated type information.




I know that this is an old question, but I had the same issue and nothing from above helped me. So I hope my answer will be helpful for somebody. In my case the problem was in ALWAYS_SEARCH_USER_PATHS setting. When it was set to NO project built and worked ok. But as far as one of the pod required it to be set to YES I was receiving an error

Include of non-modular header inside framework module

After couple cups of coffee and all day researching I found out that according to known issues of Xcode 7.1 Beta 2 release notes:

• If you get an error stating "Include of non-modular header inside framework module" for a framework that previously compiled, make sure the "Always Search User Paths" build setting is set to "No". The default is "Yes" only for legacy reasons. (22784786)

I was using XCode 7.3 though, but seems like this bug hasn't been fixed yet.




I had this exact problem when including my own framework in a project. Fixed it by putting all imports of sqlite3.h in .m files not in public .h ones. I'm assuming that other libraries may flag similar issues with Xcode.




I would like to add my experience with the problem as well.

Just to summarize :

  • @ambientlight's answer is great and it fixes most of the problems.
  • allowing non-modular headers is another solution ( see some of the answers above )
  • marking the framework's headers as public ( only the once that You want to expose ) and importing them in the umbrella header
  • here are my 2 additions to the answer
  • carefully check the imports in your project for headers which import your frameworks directly in them ( instead if using forward declaration if possible ), it is not a good practice to include a header file into another header file, sometimes this causes a problems, because if not done properly this may lead to multiple including of one header and linker issues
  • and lastly after doing all of the above, I still kept bumping onto that error, so I dug a little more and found ( in apple developer forums, but lost the link :( ), that if You include the headers in the umbrella header not like this <framework/headerName.h>, but only like this "headerName.h", the problem goes away, I tried this and for now I haven't experienced this problem anymore, however I think that this solution is valid only if You have applied some of the top answers ( they are not all compatible with each other, for example the module approach and the allowing of non modular header includes )

ADDITION : check the architectures of the library and that of the target that You want to link it to




After allowing to import non modular includes, you could try to import that module using Objective-C Bridging header:

#import <YandexMobileMetrica/YandexMobileMetrica.h>



I got this problem after updating a project from swift2 to swift3. I was using XCode 8.3.2 to update the code and could not get rid of the error “non-modular header inside framework module”. When I opened the same project in another version of XCode (version 9.0.1) the error did not appear.




I had this problem importing the Parse framework. The only way I could fix it was to discard all my changes since my last commit (simply deleting the framework and cleaning the project did not work) and add Parse again (after a fresh download of the SDK) with its other required frameworks.




Related

objective-c frameworks swift