63

Whenever I try to use a build configuration named other than 'Debug' or 'Release', Xcode suddenly cannot find my Swift frameworks. The configurations are the exact same other than their name (in fact, the new configuration was duplicated from the working 'Debug' configuration).

Build configurations screenshot

Xcode reports 'No such module'

Xcode error

This seems like a really strange bug. Surely someone has come across this before? My Google search yielded no results. Does anyone have any idea what may be causing this issue? I'm pretty sure I added the framework correctly.

I've created a short screencast to show you exactly what I'm doing: http://www.screencast.com/t/zpgZ5ZYgvH

Bottom line:

  1. Make sure project currently builds using third-party Swift frameworks
  2. Select the project in the project/file navigator
  3. Select the project above Targets in the editor left sidebar and make sure you are on the Info tab
  4. Duplicate the current configuration (likely 'Debug') by clicking the + button below the list of configurations and selecting 'Duplicate XXX Configuration'
  5. Modify your scheme to use the new configuration by going to Product (menu) > Scheme > Edit Scheme...
  6. Select Run in the left sidebar
  7. Select your new configuration under Build Configuration
  8. Attempt to build again

You can also download the sample project: http://s000.tinyupload.com/?file_id=48797763216274271820

I'm running Xcode 6.0.1 (6A317) and Yosemite 10.10 (14A361c).

DJ Tarazona
  • 1,769
  • 14
  • 18
  • +1 for your efforts ;) – HAS Oct 01 '14 at 16:35
  • 1
    @someotherguy I'm running into this too... any solution? – John Gibb Dec 02 '14 at 20:02
  • 2
    When I add configurations with the same name to the frameworks, it works... so in your case, try adding `Debug Original` to the Alamofire project... – John Gibb Dec 02 '14 at 20:12
  • @JohnGibb No solution yet. =/ Nice catch! I'll try that out soon. – DJ Tarazona Dec 05 '14 at 02:42
  • Tangentially, my understanding is that frameworks are supported only for app extensions, not for code reuse. Unless I'm wrong (or you're using it for an app extension), this means Apple would reject such an app anyway. – Gregory Higley Dec 07 '14 at 21:35
  • @GregoryHigley Hmm, I don't think that is the case as [Alamofire](https://github.com/Alamofire/Alamofire) is used in apps in the App Store. Perhaps it depends on how the framework is linked? – DJ Tarazona Dec 08 '14 at 23:00
  • Hm, looks like I'm wrong about that, and glad to be so. – Gregory Higley Dec 09 '14 at 04:20
  • I have the same issue, but for the simulator only. Did you found a solution yet? I can build for the device, but not the simulator. Any config other than Release or Debug, and so long frameworks e/ – nmdias Dec 10 '14 at 16:54
  • Nope. My builds still fail even when building for an iOS device (and not the simulator). – DJ Tarazona Dec 10 '14 at 18:24
  • So this issue is still around. I didn't have any clue that it might be a bug related to swift as my very first app is swift. :( damn – Nuno Gonçalves Nov 06 '15 at 21:56
  • I believe it is bug. Apple engineers also agree: https://twitter.com/jckarter/status/717535474789658625. Please dupe my radar: http://openradar.appspot.com/25576298. – an0 Apr 06 '16 at 15:02

4 Answers4

35

Add the following Framework Search Path in the Build Settings of your target: $(SYMROOT)/Release$(EFFECTIVE_PLATFORM_NAME) and make it non-recursive

In my case this was for Alamofire, which was added to my project as a git submodule.

The framework was being built correctly which can be seen in the build logs, but I assume the default framework search path is derived from the scheme name. The Alamofire framework & dSYM file are in Release-iphoneos/ Release-iphonesimulator.

This should work work with any Swift framework as long as it's scheme names are default. If not, check the build logs and adjust the framework search path accordingly.

James Zaghini
  • 3,895
  • 4
  • 45
  • 61
25

I had this issue as well and fixed it by adding the same configuration names to the included Alamofire project.

My build schemes in my main project: main project configs

And the build schemes inside the Alamofire project: screenshot of schemes

Note: Also, make sure your iOS deployment target is the same in both projects.

shim
  • 9,289
  • 12
  • 69
  • 108
Antoine
  • 23,526
  • 11
  • 88
  • 94
  • 2
    Thanks for reporting in. Unfortunately this isn't an ideal solution. Hopefully Apple fixes this soon. – DJ Tarazona Dec 24 '14 at 08:22
  • Thanks! I also had to do "Clean (CAP+CMD+K)" to make it work. – maxdec Mar 09 '15 at 15:56
  • THANK YOU. This saved me hours, I'm sure of it. – Epaga Oct 06 '17 at 08:20
  • @Antoine: Thanks! In above example you had Alamofire Framework project, so you were able to update build configurations, but if We have only compiled framework(Without Project) for e.g) HockeySDK.framework, Then we cant update build configurations. How to deal with such situation? Any Idea? – Gaurav Borole Jan 17 '18 at 08:54
  • I had to do this too, changing the Framework Search Path didn't help. – Guillaume Laurent Jun 28 '19 at 10:40
8

If you are using CocoaPods, try pod install this will generate some .xcconfig files with your configuration name. Clean your build folder and build again.

shim
  • 9,289
  • 12
  • 69
  • 108
Doug Amos
  • 4,243
  • 1
  • 22
  • 23
  • If you use CocoaPods, that is indeed the best option! – PlusInfinite Nov 30 '16 at 01:29
  • 1
    I have the same issue with CocoaPods. In fact, I originally ran into this error first when using CocoaPods. For the purposes of this question, I tried without CocoaPods to rule out CocoaPods as the culprit. – DJ Tarazona Jan 28 '17 at 06:34
  • 1
    I had the same issue , this solved the problem. This would be a valid solution if problem is due cocoapods – Ankit J Nov 01 '17 at 06:57
  • 2
    I tried this and it did not seem to work. CocoaLumberjack is the culprit at the moment – andrewmclean Feb 24 '18 at 19:57
1

If you have a modular structure (e.g. the App uses frameworks to decouple UI, Services or Business Logic from the application's main module) then add the new Build Configuration to each subproject that builds these frameworks.

In this case if the author had, let's say, Services Framework in his workspace then he had to add a Debug Original configuration to it too. And then run pod install, of course.

This is how I fixed my issue.

Anton Ogarkov
  • 455
  • 6
  • 14