Curious about "encoding" in `@ObjCMethod` annotation. We've been doing some experiments with cintero...

# kotlin-native

[kpgalligan]

Curious about "encoding" in @ObjCMethod annotation. We've been doing some experiments with cinterop and can successfully link and call to objc methods. As a concrete example, on iOS the objc class for Crashlytics is FIRCrashlytics. We only care about getting the global instance and logging a string, so after seeing what cinterop does, we just made this Kotlin class. It'll successfully link to the objc, and calls the methods as we expect.

@ExternalObjCClass
open class FIRCrashlytics : NSObject() {
    @ExternalObjCClass
    companion object : NSObjectMeta(), ObjCClassOf<FIRCrashlytics> {
        @ObjCMethod("crashlytics", "@16@0:8")
        external fun crashlytics(): FIRCrashlytics
    }
    @ObjCMethod(selector = "log:", encoding = "v24@0:8@16")
    open external fun log(msg: String)
}

[kpgalligan]

The encoding is a little cryptic, but you can find some references that describe it. We just copied directly from what cinterop generates. However, the encoding will be different depending on if the platform is 32 or 64 bit, with the numbers in the encoding differing by a factor of 2.

[kpgalligan]

If I just change the encodings to nonsense values, the calls still work, as (I'm told) if they're empty strings. Before we go on a crazy deep dive, I'm just wondering if the value has any impact in the way we're using it?

[Michal Klimczak]

Is crashkios2 coming? :D

[kpgalligan]

Sort of? More of an integration with logging. https://github.com/touchlab/Kermit/tree/main/crashlytics

[kpgalligan]

I'm trying to figure out if CrashKiOS should stay on it's own, or just be part of a logging library, but then you need to use that logging library. I have figured out easier cinterop by just using truncated headers. I'm not using `@ObjCMethod`directly as it doesn't really buy you a whole lot, but has potential for issues (I never got a good answer for what encoding does)