Hi, I've been trying to use SealedInterop on the f...

# touchlab-tools

[Ratul Sarna]

Hi, I've been trying to use SealedInterop on the following sealed class.

@SealedInterop.Enabled
sealed interface NativeScreen {

    data object Home : NativeScreen

    data class Song(val argument: ScreenArgument) : NativeScreen

    data class Artist(val argument: ScreenArgument) : NativeScreen
}

But the only case that is available on Swift side is .else after switching onEnum(of: nativeScreen)
Can someone help me understand why this could be happening? There are other sealed classes in the project that are working fine.

[Ratul Sarna]

Nevermind, this doesn't seem to be a SKIE issue. Removing annotation reveals that none of the subclasses are being created in ObjC.

[Filip Dolník]

Hi! This can be a SKIE issue. SKIE should export these subclasses to Obj-C even if they are not exported otherwise.

Can you send me your SKIE configuration from Gradle?

[Ratul Sarna]

Thank you for replying!
I figured this out an hour ago. It was my mistake that I'd forgotten to add the relevant sub-module in the following code block -

targets.withType<KotlinNativeTarget>().configureEach {
    binaries.withType<Framework> {}
}

[Filip Dolník]

yeah but what I don’t understand is why you were able to access the NativeScreen from Swift given you didn’t include the submodule in which it’s declared

[Ratul Sarna]

I'm not sure about that. The name of the sealed class was also weird, the module name was prefixed as such - Content_stateNativeScreen instead of NativeScreen .

[Filip Dolník]

Hm, that prefix is used if the type comes from a different library - so maybe it’s a name collision thing?
Try searching for “NativeScreen” in the Obj-C header file (build/bin/$arch/$framework/Headers)

[Ratul Sarna]

would you like me to do that before or after including the module in this block -

targets.withType<KotlinNativeTarget>().configureEach {
    binaries.withType<Framework> {}
}

[Filip Dolník]

with; but you can try both and see the difference

[Ratul Sarna]

When doing it with, the name is showing up as expected

__attribute__((swift_name("NativeScreen")))
@interface ProjectNameNativeScreen : ProjectNameBase
@end

[Filip Dolník]

yeah, without you should get something like ProjectNameModuleNameNativeScreen

[Ratul Sarna]

Yes, that was the case

[Filip Dolník]

and without you can’t find any occurences of “NativeScreenArtist”?

[Filip Dolník]

because when I try the same in my demo project, SKIE exports it for me

[Filip Dolník]

the header file contains a function called “skieTypeExports”

[Filip Dolník]

which should reference these types

[Filip Dolník]

in my case it looks like this:

__attribute__((objc_subclassing_restricted))
__attribute__((swift_name("__SkieTypeExportsKt")))
@interface Kotlin__SkieTypeExportsKt : KotlinBase
+ (void)skieTypeExportsP0:(KotlinDependencyNativeScreenArtist *)p0 p1:(KotlinDependencyNativeScreenHome *)p1 p2:(KotlinDependencyNativeScreenSong *)p2 __attribute__((swift_name("skieTypeExports(p0:p1:p2:)")));
@end

[Ratul Sarna]

Header file doesn't contain such a block for me when module is included in the target block

[Filip Dolník]

the function is not generated if it’s not needed. However, it should be needed if you don’t include it

[Ratul Sarna]

Aah okay. Let me re-check by removing the module

[Ratul Sarna]

This is strange that after reverting, the SkieTypeExports section doesn't have this particular sealed interface but it has another from the same module which is also annotated with SealedInterop.Enabled

[Ratul Sarna]

p147:(ProjectNameContent_stateIndexViewStateLoading *)
where Loading is an implementation of IndexViewState sealed interface

[Filip Dolník]

hm, this might be a bug
what version of SKIE and Kotlin do you have?

[Filip Dolník]

and what is your SKIE configuration in Gradle?

[Ratul Sarna]

the latest versions - 0.5.6 and 1.9.21

skie {
    features {
        group {
            FlowInterop.Enabled(false)
            SuspendInterop.Enabled(false)
            SealedInterop.Enabled(false)
            EnumInterop.Enabled(false)
        }
    }
}

[Filip Dolník]

that should be fine

so I think that SKIE doesn’t correctly evaluates the NativeScreen as being exported. The NativeScreen is exported by the Kotlin compiler because it is referenced in some declaration (class, function, etc.) that is exported. So my guess is that the specific way this class is referenced is not accounted for.

Can you search all occurrences of “NativeScreen” in the header file without adding the module to the binaries block and with SKIE disabled?
(you can disable SKIE by skie { isEnabled.set(false) }

[Ratul Sarna]

Can I do it in a few hours? Rushing into a meeting.

[Filip Dolník]

yeah, no problem

[Ratul Sarna]

Hi, sorry for the late reply. Here are my findings -
1. When setting skie { isEnabled.set(false) } and not including the module in binaries block, there is no mention of "NativeScreen" in the headers file.
2. After setting skie enabled to true and not including module in binaries, here are the mentions of NativeScreen in headers file -
a. @class ....., ProjectNameModuleNameNativeScreen, .....
b.

__attribute__((swift_name("ModuleNameNativeScreen")))
@interface ProjectNameModuleNameNativeScreen : ProjectNameBase
@end

As before, it is not included in SkieTypeExports section.

[Filip Dolník]

Hi! No problem

These are the only two occurrences of the ProjectNameModuleNameNativeScreen class?

Because there should be at least one extra reference somewhere (it might a return type or value parameter of some function, or an inheritance relation)

[Ratul Sarna]

Yes, I've included NativeScreen as a property in another class, but didn't share because that is a project specific thing and I thought if I hadn't used it in the class, the block would not exist.

[Ratul Sarna]

Here it is -

__attribute__((objc_subclassing_restricted))
__attribute__((swift_name("ModuleNameNativeNavigationDescriptor")))
@interface ProjectNameModuleNameNativeNavigationDescriptor : ProjectNameBase
@property (readonly) BOOL clearScreenStack __attribute__((swift_name("clearScreenStack")));
@property (readonly) ProjectNameModuleNameNativeScreen *screen __attribute__((swift_name("screen")));
- (instancetype)initWithScreen:(ProjectNameModuleNameNativeScreen *)screen clearScreenStack:(BOOL)clearScreenStack __attribute__((swift_name("init(screen:clearScreenStack:)"))) __attribute__((objc_designated_initializer));
- (ProjectNameModuleNameNativeNavigationDescriptor *)doCopyScreen:(ProjectNameModuleNameNativeScreen *)screen clearScreenStack:(BOOL)clearScreenStack __attribute__((swift_name("doCopy(screen:clearScreenStack:)")));
- (BOOL)isEqual:(id _Nullable)other __attribute__((swift_name("isEqual(_:)")));
- (NSUInteger)hash __attribute__((swift_name("hash()")));
- (NSString *)description __attribute__((swift_name("description()")));
@end

[Filip Dolník]

thanks

[Filip Dolník]

so if I understand correctly, this is a data class?

data class NativeNavigationDescriptor(
    val screen: NativeScreen, 
    val clearScreenStack: Boolean,
)

[Ratul Sarna]

yes

[Filip Dolník]

ok, I’ll try that locally

[Filip Dolník]

nice I have a reproducer!

[Ratul Sarna]

that's great!

[Filip Dolník]

Thanks for your help!

The problem is a little bit more complex because it’s two SKIE features not working correctly together:

The important missing piece in the puzzle is this code:

val foo: Flow<NativeNavigationDescriptor>

SKIE also automatically exports a class used exclusively in the Flow type argument because Kotlin doesn’t do that (it doesn’t need to because without SKIE the type argument is erased)

This is handled by the same code as for the sealed classes and the code is supposed to support this, but there is some bug in it.

[Filip Dolník]

so if you added this code to your exported module instead:

val foo: NativeNavigationDescriptor

it would work as expected

[Ratul Sarna]

aah Okay. That makes sense. Overlapping targets need to be processed by the same code and this exact scenario might have some issue that got missed.

[Ratul Sarna]

Thanks for taking the time to look into this! Should I file an issue on github for tracking sake?

[Filip Dolník]

You can if you want, but it’s not needed, I will create an issue in our local issue tracker and I’ll fix it hopefully in the next release

[Ratul Sarna]

Sure. Not needed then.