Swift debugger does not show variable values when importing ObjC framework

Question

When I create a new OS X "Game" project with Sprite Kit, and set a breakpoint anywhere I can see the variable values just fine:

Then I change the code to import my own framework (TilemapKit) which is a pure Objective-C framework:

import SpriteKit
import TilemapKit

class GameScene: SKScene {
    override func didMoveToView(view: SKView) {
        print("dang!")
    }
}

No other changes made. I'm not even using any of the TilemapKit code (yet). When the breakpoint triggers, I see this:

The entire project stops being debuggable as far as observing variable values goes. This behavior is perfectly consistent. Without the framework import I can debug again.

Since I'm on Xcode 7 beta (7A121l) and OS X 10.11 developer preview I know this could simply be a (temporary) bug.

Command line Tiles are set to use the Xcode 7.0 version btw. I tried enabling modules in the framework target, made sure the deployment target is the same (10.11), disabled symbol stripping. I added a Bridging Header and #imported the TilemapKit framework in it (removing the Swift import in that case would still give me the non-debuggable app, so it doesn't seem to matter how or where I import the framework).

Does anyone have a suggestion on what could cause this behavior and how I might go about fixing it - or at least how I could try to narrow down the issue?

Is the culprit more likely to be connected to the project's vs the framework's build settings? Do I need to enable something in the app project to make it compatible with ObjC frameworks? (I already got -ObjC in the Other Linker flags)

---

UPDATE:

I ran po self in the debug console and found this notice:

<built-in>:3:6: error: module 'TilemapKit' was built in directory '/TilemapKit.framework' but now resides in directory './TilemapKit.framework'
#define __clang_major__ 7
     ^
missing required module 'TilemapKit'
Debug info from this module will be unavailable in the debugger.

How come the framework build directory changed? And why would that matter and how to fix this?

PS: the same framework in a new ObjC app can be debugged just fine.

Bouchard

Even I am facing same issue with new a set of Frameworks provided by Twitter. Unable to debug anything. Just shows only variable names and nothing other than that. For me it shows this error. error: module 'Fabric' was built in directory '/Fabric.framework' but now resides in directory './Fabric.framework' – Outflank

Good to know, sounds like a general issue. – Bouchard

The same issue in XCode7beta3 – Cornet

Xcode 11.2.1 still happens, honestly Apple. 5 years issue. – Proconsul

Answer 1

I got a message from an Apple developer stating that they've observed this problem, and that it could be fixed by moving the .framework to a subfolder of the project.

Apparently the module .. was built in directory error appears only if the .framework is in the same folder as the .xcodeproj aka $(PROJECT_DIR).

However moving the framework to a subfolder didn't fix the issue in my case, but it's still worth a try until this gets fixed in a newer Xcode 7 beta (still occurs in beta 3).

Bouchard

i've just confirmed this works. you also need to update Framework Search Paths in Build Settings – Depew

This solution fixed half of the issue in my case. Frameworks for Facebook and Parse were installed at the project level and moving them in a subfolder worked. But other frameworks like Alamofire and SwiftyJSON, installed with Carthage and then set as "Embedded Binaries" were still triggering the issue. Adding a "/" at the end of the framework search path for Carthage completely fixed the problem. "$(PROJECT_DIR)/Carthage/Build/iOS/" – Samuelson

Can't upvote this enough. Debugger is back in business. – Waverley

Answer 2

In my case this was happening because of redundant import statements in my project.

My project mixes swift and objc files, so I have import statements in the bridging_header.h file.

In my bridging_header.h I had #import blah.h

In one of the swift files, I was importing a redundant header from a framework @import blah // From blah.framework

I removed the redundant import from the swift file, that seems to have fixed it.

Polypus

For me it was necessary to remove the import headers from a bridging header and to add framework imports to the swift files. – Sackbut

this works great. I've installed openSSL via cocoapods and it broke the debugger. After inspecting the bridging header I noticed that pkcs7.h was already declared elsewhere. after commenting it out it started working again. such a stupid thing and 2 hours gone – Sampler

Answer 3

I can confirm this is happening in Xcode Version 7.0 beta 4 (7A165t). I had to remove my ObjC framework to get Debugging values to return. If removing your framework isn't an option, the print method is old-school debugging, but still works.

Teamwork

Answer 4

I had this issue a while ago. In my case the Prefix.pch was beeing included inside the Bridging-Header.h. This is not a issue per so, but inside my Prefix.pch there was many C includes that make the lldb fail to import the Bridging-Header. So I removed the "#import Prefix.pch" from the Bridging-Header and copied just the "#includes" to the obj-c files that I need to use in swift.

Punnet

Answer 5

1. The Optimization level is not set to None for the Debug configuration. Be sure to set it to None for Objective-C apps as shown in Figure 1 and for Swift apps as shown in Figure 2.

2. The Build Configuration pop-up menu is set to Release in the scheme editor's Run action settings pane. In Xcode, open the scheme editor by choosing Product > Scheme > Edit Scheme…, select the Run action for your app in the scheme actions pane, then set Build Configuration to Debug as seen in Figure 3.

Prudhoe

Answer 6

Go to Edit Scheme on left top corner.

And change the configurations to Debug, if it is release

Rhomboid

Like I said, the problem goes away as soon as I comment out the import line. Of course it's a debug build. – Bouchard

OP showed that he was able to see the variables, which is only possible in Debug. The change he made was include an import. – Fidole