logoalt Hacker News

Using Go for Mobile Apps

31 pointsby theHocineSaadtoday at 9:28 AM9 commentsview on HN

Comments

dizhntoday at 1:36 PM

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?)

show 1 reply
iamcalledrobtoday at 1:33 PM

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.

show 2 replies
nasretdinovtoday at 1:14 PM

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

show 1 reply
kqrtoday at 1:34 PM

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!