I've built and shipped some native-UI cross-platform apps to millions of devices, powered by a Go shared library. It works. It's fantastic to use the same language on client and server, and the end-to-end testing story is really strong.
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.
Given that even on Linux DNS resolution in Go can be quite... interesting without CGO being enabled, honestly it's hardly surprising that on iOS it would also be quite challenging.
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
Vaguely related realisation I had a couple of years ago: if you don't need a complicated mobile app, but just something simple for your own use, you can write and run Perl scripts in Termux and there you go – an app, without learning any Android at all!
I don't get why with all the plumbing the author already set up, Go had to be part of the mobile app at all. Could have been a clean flutter/dart UI with a Go backend. (All of these they already have but somehow they have to deal with passing binary data between Go mobile and dart?)