Best tooling for wide platform support

Providing inclusion for all platforms, such as JVM, JS, Apple ecosystem, etc… favours the adoption of the TBD SDKs.

Kotlin Multiplatform (KMP) is probably the best choice for sharing logic across different platforms. It supports a wide range of targets while providing the capability to abstract away native implementations.

As far as I know, the SSI-Service and the SSI-SDK were written in Go to easily adopt them in a Mobile context with the help of GoMobile. Speaking from a mobile developer’s perspective, I think Kotlin Multiplatform can provide a more native-like SDK on mobile, and I’d choose such an SDK more willingly.

I’m opening this discussion both as my suggestion to the TBD team for using KMP and to open up any questions that such a decision might have.

I work with KMP libraries daily while developing a production mobile app in KMP, so I’m happy to help with what I can.
Additionally, Cashapp uses Kotlin Multiplatform in many of their libraries (one such example is cashapp/sqldelight), so maybe knowledge sharing inside Block is also possible. :slightly_smiling_face:

1 Like

Hi @nrobi and thanks for the post.

My experience with GoMobile has mostly been direct (just providing such a lib to a mobile developer). The benefit I saw was being able to re-use the Go Library code that contained sensitive functions (such as crypto operations for signing and verifying data) in addition to key generation, and only implementing certain protocols in a single place.

For example, the ssi-sdk impelments the Presentation Exchange specification here, and could expose method bindings that make a mobile developer simply take advantage of the existing work, and guarantee the same code is being used on a backend server (as it could be used in the ssi-service) and the mobile app.

I do not have familiarity with KMP. What would the process be like? Would the existing ssi-sdk have any utility, or would it require a re-write in Kotlin?

Similarly, I know that Android is JVM focused, so Kotlin shouldn’t be an issue. What’s the experience with it working in Swift?

1 Like

Hey @decentralgabe, I’ll try my best to address your questions

To outline the purpose, we want the best tool - whether it’s Go/GoMobile, KMP or other - to write a given protocol once and use it on as many platforms as possible, additionally providing the best experience for the library consumers.

Now about the implementation details:

  • Yes, the ssi-sdk will need a rewrite in KMP. For that reason trying it out on the tbdex-protocol might be smarter if a rewrite is already planned. I’m happy to create a KMP example based on one of the tbDEX Projects.
  • The output binary for iOS/Swift might be similar to GoMobile. It generates Obj-C bindings that can be consumed by Obj-C/Swift code.

One question from me is how easy it is to provide the native implementation for something in GoMobile? Let’s say we want to use a File in the SDK, that has different meanings on iOS/JVM/Android/macOS.
In KMP it’s fairly easy to use native dependencies to provide these implementations, even cocoapods can be used to pull in iOS dependencies (that have Obj-C bindings, so pure Swift code isn’t possible)

Two additional points about KMP:

  • One of the strengths of KMP is that it’s easy to handle platform-specific questions in the library. I recommend checking out this example of how the meaning of an “Image” is abstracted from platform-specific meanings:

    1. The “Image” abstraction in the shared code - https:// github .com/halcyonmobile/MultiplatformPlayground/blob/master/common/src/commonMain/kotlin/com/halcyonmobile/multiplatformplayground/shared/util/File.kt

    2. The Android “Image” https:// github .com/halcyonmobile/MultiplatformPlayground/blob/master/common/src/androidMain/kotlin/com/halcyonmobile/multiplatformplayground/shared/util/File.kt

    3. The iOS “Image” https:// github .com/halcyonmobile/MultiplatformPlayground/blob/master/common/src/iosMain/kotlin/com/halcyonmobile/multiplatformplayground/shared/util/File.kt

    Of course, this is possible with an Interface/Implementation abstraction, but with the above typealias format, the platforms receive the native representation (NSImage - iOS, ImageUri - Android, instead of the abstracted FileImage)

  • I recommend the Case Studies for other companies’ experience with KMP. In addition, I’m happy to share Octopus Energy’s angle, as we’ve been using KMP in production for more than a year (including ~10 iOS engineers)

With all that said, I have limited exposure to GoMobile, and I first heard of it from TBD, so I’m up for getting my feet wet and trying to find possible issues from a library consumer’s perspective.

One experimentation idea could be to compare a 1) KMP tbdex-protocol artifact with a 2) GoMobile SSI-SDK. @decentralgabe, let me know if I can help out with any action items

PS: sorry for butchering the links, apparently new users can only put 2 links in a post

Thanks for the detailed reply!

It sounds like such a library would not really have native utility for both iOS and Android. I cannot comfortably answer the specifics of file/image abstractions.

The best case would be if we have a need for a JVM-based SSI-SDK, that has proven interoperability with the Go-based version. This would allow us to use KMP in the Android app at the least, in addition to other JVM-based software.

Additionally, seeing that one of the case studies you linked is from Cash App is a great sign, since we have the same parent company. We’ll be able to talk to the mobile team members and learn from their experience and existing infrastructure we may be able to leverage internally.

I do believe the future is multi language, and having SDKs with broad language support is a goal. That said - until we build out our mobile team in house, there’s not much of a plan, but lots of good context for when they come on in the next few months!

1 Like