January 7

Playing Nicely Together: Swift, Dependencies and Cocoapods

We recently pushed out version 2.2.2 of our Aeris Weather SDK for iOS to fix some issues with using Objective-C and Swift modules in Xcode 7 and Cocoapods. While tweaking our internal projects to better support modules, we ran into this dreaded compiler error in Swift 1.2 when trying to build the updated libraries:

Screen-Shot-2016-01-07-at-9.20.19-AM

And apparently we weren’t alone.

There were many of these errors and they all appeared within the umbrella headers of each of our frameworks, Aeris.h for example. At first we figured it was some weirdness caused by using our ObjC Aeris libraries in a Swift project, but our libraries were being included in the project’s bridging header properly.

When confronted with this error, there are of course more common things to check. First, make sure all headers that should be public and are listed in the framework’s umbrella header are flagged as public within the library’s project under the file’s Target Membership. In our case this wasn’t the cause. So then the second thing to check is your project’s build settings and make sure the value for Allow Non-modular Header Includes in Framework Modules is set to YES, which is a new build setting in Xcode 7:

Xcode Non-modular Headers Build Setting

Additionally, if you are using Cocoapods for including other dependencies in your project you’ll also need to set this build setting to YES for each pod. A quick and painless way to do this is add a post_install action in your project’s Podfile to set this automatically:


In many cases going through these two steps will fix your issues. But alas, we were still plagued by the same non-modular header error from our Aeris frameworks.

After hours of endless browsing online and trying many different things with our project in search of a solution, we finally came across a thread on Apple’s developer forums that included a response from someone on Apple’s staff, so that had to be the answer right? Here’s his response with emphasis placed on the cause of our issue:

This happens because in 7.1:

The Swift compiler is stricter about including non-modular header files than it was in previous releases. Debugging a Swift target requires that frameworks be properly modular, meaning all of the publicly-imported headers are either accounted for in the framework’s umbrella header, are imported from another modular framework, or are listed explicitly in a custom module.modulemap file (advanced users only).

The compiler will run into issues if the same header file is accessible both through Header Search Paths (‘-I’, ‘-isystem’) and Framework Search Paths (‘-F’, ‘-iframework’), even if there are symbolic links involved. In these cases, you should prefer using Framework Search Paths. (Note that this invalid configuration may be generated by external systems, such as CocoaPods.)

Unfortunately, CocoaPods can commonly create header search paths that let the compiler find headers at a location which does not appear (to the compiler) to be a part of a module.

NOTE: The “Allow Non-modular includes in Framework Modules” build setting does not apply to Swift (and it would not be safe if it did, Swift requires access to modules for proper debugging support).

That was it! Since our Aeris libraries are frameworks, they are being included in the Framework Search Paths build setting of our project. But since we’re including it via Cocoapods, Cocoapods is also including the path to the header files in the project’s Header Search Paths in the Cocoapod’s configuration file your project’s target is inheriting. Simply adjust your target’s Header Search Paths build setting and either remove the path pointing to the libraries public headers, or simply remove the $(inherited) line to prevent inheriting Cocoapod’s header search paths:

Xcode Header Search Path Build Setting

 

Once we made this simple, but highly unknown, change to our project, the compiler was once again satisfied and our project was building properly using our Aeris frameworks as modules via Cocoapods. Hopefully this post will save someone out there a lot of time and headache trying to track down the cause of this error they are also seeing.


We’re constantly updating and improving our Aeris iOS SDKs to use the latest iOS APIs and have many more things planned for them in 2016. So sign up for our Aeris Weather API, download our latest iOS SDKs and start building your own Aeris-powered apps! 

2 Comments

  1. January 22, 2016 at 2:42 pm

    Fought the same issue today. Dealing with compiler issues like this, man it’s the worst, but this was the final clue that helped me figure it out. Props for taking the time to share.

  2. February 3, 2016 at 10:11 pm

    I love what you guys are up too. Such clever work and exposure!

    Keep up the awesome works guys I’ve added you guys to
    our blogroll.

Leave a Reply

Your email address will not be published. Required fields are marked *