Rendered at 16:42:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
iamcalledrob 1 days ago [-]
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.
gen2brain 1 days ago [-]
I did something similar with `go bind`, a library used on both desktop and Android, they simply exchanged JSON, though not on millions of devices. However, today I have a nice cross-platform UI library with native controls, based on IUP, where cross-platform actually means everything, including iOS and Android (and even Haiku). So, you write an app in plain Go, just once, that's it. OK, you would not want the same layout on desktop and mobile, of course, but still the same app.
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 .
scosman 1 days ago [-]
Go mobile definitely supports building libraries. It will package up an xcframework for iOS and something else for Android (I forget details). It doesn't need to be the whole app. You get nice(ish) language bindings.
That said, a pure c framework is probably a cleaner way to go.
pjmlp 1 days ago [-]
Small correction, Android doesn't speak JVM, it speaks ART, and it isn't exactly the same.
frizlab 19 hours ago [-]
I use the same language everywhere, but Swift (:
dizhn 1 days ago [-]
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?)
pjmlp 1 days ago [-]
Some people love to make their life harder.
I have long time ago learned to use the official SDK languages for a language and be done with it.
ventana 1 days ago [-]
The author uses Flutter for UI, Golang binary for the app backend, and uses channels passing serialized protobuf messages between them. Since adding a new API call requires changes in multiple places, they ended up defining a "god message" which has a oneof with all possible options:
and then dispatch the call using switch to check the value of the api field.
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.
I don’t get it. Why not just use dart for the app backend? I understand not using it on the server because it’s not mature there.
ventana 22 hours ago [-]
I don't know! The author chose to use Golang, maybe it's for code reuse or just because they like Golang more. I did not question their choice, only commented on the implementation detail.
Bratmon 19 hours ago [-]
HN upvotes
ruicraveiro 5 hours ago [-]
Hi OP, I don't know if it helps with your issues, but some years ago I wrote an article precisely about using protobuf between Dart and Go and it included a section on async: https://tech.craveiro.pt/go-for-dart-with-protocol-buffers.
nasretdinov 1 days ago [-]
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
gen2brain 1 days ago [-]
Who enables CGO just for DNS resolution? That is not a thing for a long time, you just reminded me of that. Sure, if you have some complex config instead of a simple default, you would want to use libc and getaddrinfo, that is on you. What other issues are there? Go simple uses the network protocol for DNS, and it reads just resolve.conf; it does not care about LDAP or NSS or whatever there is.
aforwardslash 18 hours ago [-]
Me. You know nuclei is written in go? Sometimes you need resolution consistency between eg. A port scanner and nuclei. You build and test this on your infra, but then you need to deploy on a heavily proxied network and you find issues. Is this your fault? Yes. Because you use golang. (Note: I use golang for almost everything, and this is something it is not documented enough - I am aware of this and have been bitten in the ass by this more than once)
nasretdinov 1 days ago [-]
> if you have some complex config instead of a simple default
Yup, exactly that. You don't always control the environment in which your software is going to run...
lukax 22 hours ago [-]
I can highly recommend Rust for this. The same Rust engine powering web app (WASM + React), iOS (SwiftUI), Android (Kotlin Compose) and desktop (Tauri).
Honestly nowadays Swift seems a better fit IMHO, though it is probably a matter of taste.
theplumber 18 hours ago [-]
Is there any chance now that we have AI to also have API bindings from iOS/android to Go? That was a deal breaker last time I’ve used go for mobile apps. Somehow you were left with no choice but a kind of electronic/web view app.
kqr 1 days ago [-]
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!
georgemcbay 1 days ago [-]
Go is my favorite language of all time, but it is my favorite language because of its inherent simplicity for a modernish language...and all the setups required to try to use it as mobile app development platform that I've seen are the opposite of simplicity.
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.
iamcalledrob 24 hours ago [-]
KMP is brilliant and arguably the best way to write a cross platform app that has Android as a target.
But what you can do with it on non-JVM platforms is a bit lacking. There are few libraries and the stdlib is rather minimal.
If you're just making some http calls and instantiating models it's pretty good though!
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.
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 .
That said, a pure c framework is probably a cleaner way to go.
I have long time ago learned to use the official SDK languages for a language and be done with it.
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
Yup, exactly that. You don't always control the environment in which your software is going to run...
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.
But what you can do with it on non-JVM platforms is a bit lacking. There are few libraries and the stdlib is rather minimal.
If you're just making some http calls and instantiating models it's pretty good though!
Shame it's part of the Grade hellscape though ;)