Cannot debug Swift module/framework embedded in Objective-C app

Question

Alternative titles (to aid searching)

Cannot debug Swift 2.3 framework linked to an Objective-C app in Xcode 8

error in auto-import: failed to get module 'XYZ' from AST context Xcode 8

Xcode 8 cannot debug Swift framework

warning: Swift error in module <XYZ>

Workaround for; Xcode Debugger cannot debug apps written in Objective-C only but that link against frameworks written in Swift only. (28312362)

I have an app written in Objective-C that links against some modules (frameworks) written in Swift 2.x.

Question

Everything (debugging etc.) works fine in xcode7, however when moving to xcode8 and updating the modules to use swift2.3 I was unable to debug the modules.

LLDB reported these errors:

warning: Swift error in module XYZ.
Debug info from this module will be unavailable in the debugger.

error: in auto-import:
failed to get module 'ABC' from AST context

This does not happen if I link the modules to an app built in Swift 2.3.

score 19 · Answer 1 · edited Jun 04 '19 at 01:13

19

For me it was just as simple as it was painful and time consuming:

import SDWebImage was the PROBLEM, because one of the frameworks had the SDWebImage already packed in it(and I couldn't see it), and that framework happened to be Objective-C, and the app was Swift. I also added the SDWebImage to the project, because I use it in the classes I write, and that what created the mess the Xcode debugger couldn't deal with. So basically, make sure you don't have ANYTHING duplicated in ANY way, I'd check for common things like SDWebImage for example.

edited Jun 04 '19 at 01:13

mokagio

16,391
3
51
58

answered Jan 26 '17 at 15:02

Tim Friedland

1,045
11
18

1

I had the exact same issue, thanks for pointing towards this. – userx Mar 06 '17 at 07:41
1

@Tim Friedland same problem with JSON model framework thanks for the answer – SARATH SASI Aug 14 '17 at 09:03
1

yes perfect answer.. save my lots of time. thanks @Tim Friedland – PALAK Mobile Team Leader Mar 09 '18 at 12:49
1

In my case, I was using SDWebImage as well as FirebaseUI (which depends on SDWebImage) and importing both in Swift. Moving these imports to my bridging header solved the problem for me. – Mick MacCallum Sep 26 '18 at 18:49

Suresh Kansujiya · Answer 2 · 2018-01-09T05:43:32.500

11

use fr v instead po for debugging

For more debugging https://www.codeproject.com/Articles/1181358/Debugging-with-Xcode

edited Jan 09 '18 at 05:43

answered Aug 20 '17 at 15:24

Suresh Kansujiya

175
1
9

1

`fr v` stands for "frame variable". More info is available at the [LLDB Debugging Guide](https://developer.apple.com/library/content/documentation/General/Conceptual/lldb-guide/chapters/C5-Examining-The-Call-Stack.html) – leanne Oct 19 '17 at 22:12
3

Seems like not a solution since frame variables anyway you can see on left panel of your console which doesn't have all necessary output. – Injectios Mar 13 '18 at 15:54

score 9 · Answer 3 · edited Jun 29 '17 at 15:06

9

I discussed this issue with an Apple engineer named Sean at WWDC 2017.

My team spent weeks trying to figure this out, and it ended up being a bug on Apple's compiler, which we could never have figured out by ourselves. Also, it has a VERY easy workaround.

There happens to be a bug with the way the compiling flags get aggregated from the frameworks and the project, and the "pure Objective-C" project "activates" it.

Solution: add one single, empty Swift file ("Whatever.swift", or whatever) in your Objective-C project, making it not-pure-objective-c anymore (new->file->Swift file, don't create the bridging header. The file will only contain the import of Foundation).

And that's it. Problem solved.

edited Jun 29 '17 at 15:06

jscs

63,694
13
151
195

answered Jun 08 '17 at 23:24

fredericouimet

151
1
5

Do you happen to have a rdar or Swift bug number associated with this? – Dmitry Shevchenko Jul 20 '17 at 20:30
To fix debugging for a project with only tests in Swift, you still need to add an empty Swift that targets the project. Adding just the Swift test file is not enough. In case anyone else comes across this solution and is only wanting to write tests in Swift. – Psiticosis Feb 21 '18 at 03:08

score 6 · Accepted Answer · edited Jun 20 '20 at 09:12

6

tl:dr

Add a user defined setting under "Build Settings" for your app target.

SWIFT_VERSION = 2.3

More Info

I'm unsure if this is an Xcode 8 bug or if it's Apple policy (to try an force developers to Swift 3.0?). But... by default Xcode 8 installs the Swift 3.0 versions of the standard Swift runtime libraries.

When it comes to debugging with LLDM the Swift 2.3 modules fail to load (in to the Swift 3.0 runtime).

Forcing the app to use Swift 2.3 (or legacy Swift as Apple call it), fixes the issue.

Swift apps have this setting exposed by Xcode but you have to manually add it for an Objective-C app.

Further Advice

Port your Swift 2.3 code to Swift 3.0 as soon as possible, Apple won't support 2.x for very long.

edited Jun 20 '20 at 09:12

Community

1
1

answered Sep 13 '16 at 10:22

Richard Stelling

25,607
27
108
188

Xcode 8.0 will try to determine which version of Swift you are using and choose the appropriate toolchain. Something in how your project is set up is defeating that detection. For instance, Xcode will choose the latest toolchain available, which happens to also be the Swift 3.0 one, for a pure ObjC project. Maybe, for instance, Xcode isn't looking through dependent sub-projects or targets of pure ObjC targets to see if there is any Swift around in them? That seems worth filing a bug about. – Jim Ingham Sep 13 '16 at 19:27
This isn't working for us, for some reason. Explicitly setting a `swift_version` (labelled in 8A218a as "Use Legacy Swift Language Version") doesn't affect the results. – David Lord Oct 11 '16 at 04:38
@DavidLord "Use Legacy Swift Language Version" is different, this is used to tell Xcode you want to use Swift 2.x and not 3.x, in the above scenario this would be set on the Framework target. `SWIFT_VERSION` should be set on the (Objective-C) app target. Hope this helps! – Richard Stelling Oct 11 '16 at 14:23
Ah - indeed! So much of the problem you've described applies to our pure Swift project, but we have no Obj-C linking in Swift modules. Thanks for the Q&A, will keep experimenting (or do without LLDB until we move to Swift 3). – David Lord Oct 11 '16 at 23:24
The "error in auto-import" thing is probably a general diagnostic that could represent any number of different errors. I'm getting the same error, but not the message that tells me *which* module is causing it, leading me to suspect it's a different issue altogether. And I've double-checked that swift_version is set correctly. – David Goodine Nov 10 '16 at 16:22
`There already is another setting named "SWIFT_VERSION". Please enter a different name.` – Vyachaslav Gerchicov Jun 19 '19 at 10:13

score 2 · Answer 5 · answered Nov 30 '16 at 08:54

2

In my case, I had to remove Objective-C Bridging header from build settings file. My Bridging header file did not do anything.. so it was okay.

answered Nov 30 '16 at 08:54

Chamira Fernando

6,836
3
23
23

score 2 · Answer 6 · answered Mar 23 '17 at 13:42

2

I ran into the error in auto-import: failed to get module 'XYZ' from AST context message while attempting to debug in an 9.3 simulator. Switching to a 10.2 simulator resolved the issue.

answered Mar 23 '17 at 13:42

Jason Moore

7,169
1
44
45

score 2 · Answer 7 · answered Mar 14 '18 at 20:47

I ran into this when building a framework with Carthage. Trying to debug would print the error, which referenced an Obj-C framework dependency.

I found this blog post which suggested adding a the following user-defined build setting to my project:

For Debug: REMOVE_HEADERS_FROM_EMBEDDED_BUNDLES = NO

For Release: REMOVE_HEADERS_FROM_EMBEDDED_BUNDLES = YES

This fixed the issue for me.

score 0 · Answer 8 · answered Oct 12 '17 at 07:40

0

Try to restart Xcode. In my case it resolved an issue.

answered Oct 12 '17 at 07:40

saltwat5r

1,107
13
21

score 0 · Answer 9 · answered Oct 24 '17 at 20:40

0

In my case there was a compiler error in the "C" code which was reported in LLDB, after fixing the error LLDB started working again.

answered Oct 24 '17 at 20:40

mbonness

1,612
1
18
20

micmdk · Answer 10 · 2018-01-31T12:30:50.230

As suggested by Tim https://stackoverflow.com/a/41876400/1840269 the root cause to our problem was a matter of duplicates.

We had a obj-c wrapper category for SDWebImage that was used from both obj-c and Swift. When Importing the category from Swift everything blew up because of redefinition/duplicate import since the SDWebImage pod already exposed it self as a Swift module.

The solution? We re-implemented the obj-c category as a Swift extension - and kept using it from both Swift and obj-c by adding @objc in front of the extension and importing the #import "product-Swift.h" file from obj-c.

And maybe start with checking: https://developer.apple.com/library/content/qa/qa1947/_index.html.

score 0 · Answer 11 · answered Feb 13 '19 at 03:55

I just took 2 days for me to resolve and debugging through print command all the time. Now I got the issue:

My project is in Swift and I was using objective-C library same as imported in pods for swift(old Objective-C project merged in this one) and was using import IQKeyboardManager as well as import "IQKeyboardManager.h" header as well. That conflicts and deleting the header one resolved my issue finally. You can check with this type of duplicity in libraries.

Cannot debug Swift module/framework embedded in Objective-C app

Alternative titles (to aid searching)

Question

11 Answers11

tl:dr

More Info

Further Advice

Linked