IMO the implementation (for me at least) is ... terrible. Why reach for this when it's, at the end of the day, just the exact same as NDK work in C++ but in Swift.
You have to use Kotlin / Other UI setup anyways (or their fully-native example, use OpenGL to draw the screen[0]), and on top of that statically assign the package path and class name in the Swift code, while making it an external func in the kotlin code[1]. You then also get to deal with the annoyances that come up with native libs.
kotlin side:
/*
* A native method that is implemented by the 'helloswift' native library,
* which is packaged with this application.
*/
external fun stringFromSwift(): String
swift side:
@_cdecl("Java_org_example_helloswift_MainActivity_stringFromSwift")
It's worth pointing out that the example you linked with the cdecl is not showcasing the swift-java interoperability but using "raw" JNI patterns as if you would do it with C.
You have to use Kotlin / Other UI setup anyways (or their fully-native example, use OpenGL to draw the screen[0]), and on top of that statically assign the package path and class name in the Swift code, while making it an external func in the kotlin code[1]. You then also get to deal with the annoyances that come up with native libs.
kotlin side: /* * A native method that is implemented by the 'helloswift' native library, * which is packaged with this application. */ external fun stringFromSwift(): String
swift side: @_cdecl("Java_org_example_helloswift_MainActivity_stringFromSwift")
[0]: https://github.com/swiftlang/swift-android-examples/blob/mai...
[1]: https://github.com/swiftlang/swift-android-examples/tree/mai...