'FrameworkName' is not a member type of 'FrameworkName' errors inside swiftinterface

Hey all,

I've been trying to create a XCFramework and having some difficulties with the .swiftinterface file that presents error. I've created a sample project to simplify the problem:

This is my framework code:

import UIKit

@objc public class LoveThis: NSObject {
    
    @objc public enum GreatEnum : NSInteger {
        case First
        case Second
    }
    
     @objc public static func helloWorld(){
        print("Hello World!")
    }
    
     @objc public static func helloGreatEnum(myEnum: GreatEnum){
        print("GreatEnum")
    }
    
    @objc public static func helloAwesomeEnum(myEnum: AwesomeEnum){
        print("AwesomeEnum")
    }
}

@objc public enum AwesomeEnum : NSInteger {
    case First
    case Second
}

After I've create my XCFramework, trying to import it gives me "Failed to load module"
and these errors:

What am I doing wrong?

It's not your fault; it's a longstanding bug/limitation in Swift that if you have a type and a framework with the same name, the name is always assumed to refer to the type. @brentdax is looking at some alternate ways to provide a module name in Pitch: Fully qualified name syntax that the module interface generator will be able to use; for now, though, you can work around this issue by renaming either your framework or the type in it. :-(

1 Like

Thanks for the quick reply!

My framework is already in production so I'm not so inclined to change the name of the framework or type.
Another work around I've found is to process the .swiftinterface files using a script and remove all the occurrences of LoveThis. which yields valid .swiftinterface files.
It seems like everything is working as it should after that. No idea if there are any pitfalls I'm not aware of.

@jrose Would you consider this a valid workaround?

It's not a 100% valid workaround because now you're relying on the unqualified types always having the same behavior even if your dependencies change. I don't foresee any problems if you ship that way today, but one of the goals of module interfaces is to work with next year's Swift and next year's dependent libraries, and that only applies to module interfaces as generated from the compiler.

1 Like

Thanks @jrose.

While I keep my eye on the discussion you linked above, is there a formal bug number\report\ticket for this I can track?

https://bugs.swift.org/browse/SR-898

1 Like
Terms of Service

Privacy Policy

Cookie Policy