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.
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.
That said, a pure c framework is probably a cleaner way to go.
However, it is still a work in progress, and I would like to improve the mobile support. There are currently many Android-only or iOS-only attributes, but users would still miss some APIs. What are the most essential OS APIs one would need in the app? You can check the library here https://github.com/gen2brain/iup-go .
I have long time ago learned to use the official SDK languages for a language and be done with it.
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
Yup, exactly that. You don't always control the environment in which your software is going to run...
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 so 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.