However, in my opinion, "Go Mobile" is a bit of a red herring if you just want a cross-platform shared library. I wouldn't recommend starting there.

It's optimised for writing and packaging an entire app in Go. Incremental builds don't work well (or at all), and cobbled-together "build system" is more to debug. It's also oriented around iOS and Android, which isn't great if you eventually want a native desktop app too. The generated bindings are okay, but the author's approach of using Protobuf (or some kind of wire format + simple API) means you don't really need them.

I found that it's more straightforward to just compile Go code into a library that can be called from C -- and thus can be called from anywhere. Call into it natively from Swift, and via JNI on Android and desktop JVM. With the right toolchain, you can cross-compile pretty easily too.

The biggest issue is that on Android you often want to talk to the OS, but the OS only speaks JVM. https://github.com/timob/jnigi "solves" this, although you will hate your life manually constructing JVM calls that you can't easily test.

  message CarrotAPI {
    oneof api {
      Function1API function1 = 10;
      Function2API function2 = 11;
    }
  }
  
  message Function1API {
        message Request {}
        message Response {}
        
        Request request = 1;
        Response response = 2;
  }

This is... not really a good API design. I wonder if the problem of "multiple places to be edited" can be solved in an easier way by making a custom protoc plugin [1] which will take care of generating all the boilerplate for both Dart and Golang. This is how support for new languages and use cases is normally added to protoc.

[1]: https://protobuf.dev/reference/other/

I imagine that one more interesting thing to consider is that on iOS you can't fork() or spawn sub-processes, so your Go mobile app is indeed running simultaneously as a Go binary and the UI, and there probably can exist countless interactions between the two being unaware of each other that might cause issues

https://github.com/koofr/vault

When it comes to mobile app development I'll stick to Kotlin Multiplatform with Compose Multiplatform. I love Kotlin less than I love Go, but its still pretty good and its much simpler to write 99% of the app in Kotlin and Compose and just have a very small amount of platform-specific stuff in expect/actual functions than it is to deal with layers and layers of shims pulling together various technologies that were not designed to work together.